What's the problem with 30023 that wouldn't affect a new event kind?
It occurred to me that NIP-13 only on kind 0s accomplishes my PoW goals pretty well. Clients can support that (somewhat inefficiently, needing to fetch the kind 0, but they tend to do that anyway) and relays can still offer several enhancements I have in mind for better efficiency.
On the fediverse markdown is very common even for microblogging, it's incredibly handy. Heck I just saw a screenshot of json on here a second ago, that would be perfect in a markdown code block.
I just listen to my schizophrenic castile soap bottle and use it for shampoo...
Hadn't heard of that before, are you talking about https://github.com/indra-labs/indra ?
Yep, https://github.com/nostr-protocol/nips/issues/717 is the main thread, you can follow the links to draft NIP 44 and NIP 24 for more detail
Ah thanks, didn't check issues and PRs, just my local copy of the nips repo. Can't wait for issues+PRs on nostr already...
Is there a NIP for this? I don't see anything for "giftwrap" in the nips repo, nor anything interesting for "DM" or "direct" outside of NIP-04
Trusted relays is a hard pill to swallow, but it's still vastly better for your relay to have metadata than for *everybody* to.
Of course, there's other major caveats (relays can notice who's subscribed to these uncorrellated keys if you're not careful), but already a big improvement imho.
Yeah for the encryption, but ecdh gives you a shared secret you can use to derive uncorellated key pairs for the DM session.
ex:
tweak(my_private_key, shared_secret) = my_dm_private_key
since ECC is nice that way, my DM partner also knows:
tweak(my_public_key, shared_secret) = my_dm_public_key
You'd need to work to defeat timing attacks between this handshake and your first DMs, but the new key pairs are publicly uncorrellated from your "normal" key pair.
ECDH seems like an obvious improvement here. You'll still leak who has started DM sessions, but it's a huge improvement over "the sender and recipient of every DM is immediately obvious" with NIP-04
To be clear, not for the adult content (that's an unfortunate but probably lucrative side effect), but because I'm extra angry at youtube lately. The adblocker stuff combined with their completely unfair treatment of 3d print general, and other gun-content related youtubers. It seems like they'll be completely marginalized soon enough, and every alternative has major caveats.
Really want to work on a nostr video service, but I already don't have enough time for my musig project lol
Is there a kind for markdown notes? I miss the expressiveness of markdown posts in fedi.
One thing I've thought about a fair bit (in the shower) is the need for oracles. As more "trading" volume moved off of exchanges, price oracles based on them become less and less accurate. Non-exchange oracles seem far too gameable with wash trading, although that obviously exists today anyway.
This becomes doubly hard with off chain DLC trades since you can't really prove they happened, and even if you could, you can't prove the parties didn't immediately reverse the trade and suppress the proof of that reversal trade.
On the other hand, I suppose all of this would be "nice problems to have". If we get to such a world, we've already halfway won.
thank *you* for coracle ;-)
https://gist.github.com/AdamISZ/b462838cbc8cc06aae0c15610502e4da ?
That was an interesting read. The single biggest limitation is probably the inability to "skip" part of the path. Otherwise you could repeat the same participants M times, to get arbitrary transfers (with an eye-watering (M * N)^2 efficiency lol).
I was also thinking a bit about spend efficiency, you can probably do better than tap-leaf-per-case (which wasn't explicitly stated, but sort of implied) by compressing multiple CSVs into one tap leaf.
And then finally, I wonder if the "vertical" portion of signature sharing could be compressed by pre-sharing them all, and having some adapter which is constant between them? (guy with only a vague, intuitive understanding of signature adapters)
Just realized my third point probably relies on a construct that doesn't exist, encumbering a musig partial signature with an adapter... but it still seems like sig_A2..AN could be pre-shared as sig'_A2..AN, and alice would send Bob k instead of sig_A2..sig_AN. *hand waves again* You math people figure it out ;-)
https://gist.github.com/AdamISZ/b462838cbc8cc06aae0c15610502e4da ?
That was an interesting read. The single biggest limitation is probably the inability to "skip" part of the path. Otherwise you could repeat the same participants M times, to get arbitrary transfers (with an eye-watering (M * N)^2 efficiency lol).
I was also thinking a bit about spend efficiency, you can probably do better than tap-leaf-per-case (which wasn't explicitly stated, but sort of implied) by compressing multiple CSVs into one tap leaf.
And then finally, I wonder if the "vertical" portion of signature sharing could be compressed by pre-sharing them all, and having some adapter which is constant between them? (guy with only a vague, intuitive understanding of signature adapters)
Does anyone use the collapse buttons in coracle? Thinking of removing them. nostr:nprofile1qqs8hhhhhc3dmrje73squpz255ape7t448w86f7ltqemca7m0p99spgpr9mhxue69uhhyetvv9ujuumwdae8gtnnda3kjctv9uqsuamnwvaz7tmwdaejumr0dshsz9thwden5te0wfjkccte9ejxzmt4wvhxjme0e8prr6 your thoughts?
I don't use them at all, but it would be *really* nice if the "Show N more replies" text could display them in the feed rather than opening a new pane (or whatever you call these things).
FWIW I don't really like the "pane"s in general, Id rather I was able to open threads in separate tabs in my browser which doesn't seem possible at present. I admit I may be in the minority here.