@Alex Gleason
I create software that empowers people online.
I'm vegan btw.
Relays (2)
- wss://relay.ditto.pub/ – read & write
- wss://relay.dreamith.to/ – read & write
Recent Notes
I downloaded the Claude models in Shakespeare AI to 4.x because the newer models are trying way too hard. I want to replace these with open source models once I have time to test them with Shakespeare.
51❤️3💜2💯1🤖1🧡1
I've been sleeping on Undertale. I'm feeling inspired. And full of determination.
Happy birthday, @RogueHashrate! 🎂🎉
1
GM ☀️ PV 🖖
New nostr:npub1car07c9zhkf7nkjh062v860gje8rf6v7m3sh0dttf5xypwvf4w7swjf0dd feature about to roll out…
Comment on any web page. 💬
This is how Nostr becomes the comment layer fo...
"Ditto is the worst thing to happen to Nostr" but you copy all its features and then lump it into "and a few other clients"
2😂1😢1🤡1
Groundbreaking
🤣1
Ahhh yeah... okay I do see it contradicts my position. We AUTH from the sender. It's not perfect.
Ditto Relay lets you AUTH as either the sender or receiver to view. But to delete you have to be the receiver. This is the biggest source of dissonance in the theory, I think. But it's not too bad. It's a weird triangle shape of requirements.
4
Is what you are saying, that the NIP17 recommendation for serve 1059 ONLY to p-tags, does not matter because hardly any relays do that? If so, then that makes sense and I acknowledge that is your sta...
Ahhh yeah... okay I do see it contradicts my position. We AUTH from the sender. It's not perfect.
1
>but relays that already protected DMs, have to turn that off or they can't serve concord groups.
This is not true. relay.ditto.pub gates giftwraps and nip04 DMs with AUTH. If you're in a Concord cha...
But yes you just AUTH with the Concord key to get the Concord stream.
1
NIP17 has basically no available methods for prevention of spam by relays.. Other than, expiry. It's all client side.. The interesting thing is that a full setup for protecting giftwraps, or offering...
>but relays that already protected DMs, have to turn that off or they can't serve concord groups.
This is not true. relay.ditto.pub gates giftwraps and nip04 DMs with AUTH. If you're in a Concord channel you hold the private key to the channel, so you just AUTH to it. It already works. Concord is perfectly compatible with NIP-17 relays except that NIP-17 doesn't explicitly state that the author shouldn't be allowed to delete. But it does say that the author should essentially throw away the key and that the recipient should be allowed to delete, so it's easy to argue that compliant NIP-17 relays _should_ prevent deletion by the author.
This is not true. relay.ditto.pub gates giftwraps and nip04 DMs with AUTH. If you're in a Concord channel you hold the private key to the channel, so you just AUTH to it. It already works. Concord is perfectly compatible with NIP-17 relays except that NIP-17 doesn't explicitly state that the author shouldn't be allowed to delete. But it does say that the author should essentially throw away the key and that the recipient should be allowed to delete, so it's easy to argue that compliant NIP-17 relays _should_ prevent deletion by the author.
2
Mostly fair assessment. We chose the better of 2 bad options. Concord v1 tagged the community instead of being authored by it, making it possible for any outsider to spam/DoS every Concord group on th...
Also, NIP-17 makes it clear that giftwraps are owned by the recipient, not the sender, which is why I think it's already in the spirit to prevent deletion by the sender. 1 person should own an event. For giftwraps the owner is the recipient, not the sender.
Well, I’m still trying to wrap my head around the protocol, and my analysis also points to a relay specialization for running Concord groups. Concord introduces special features, such as the gift‑...
Mostly fair assessment. We chose the better of 2 bad options. Concord v1 tagged the community instead of being authored by it, making it possible for any outsider to spam/DoS every Concord group on the protocol level (this is also true for NIP-17, hence the inversion).
v2 requires you to at least be a member of the group in order to have any possibility to disrupt it, which I think is the far better option. Now we harden for that case, which requires a great deal less centralization.
Hardening for the NIP-17 case requires exclusive relay centralization, in the sense that no "spammy relay" can be in the relay list at all. In the Concord case it's considered "safe" to have any relay in the list, and you want at least one or two to prevent giftwrap deletion by author - which by the way is already in the spirit of NIP-17.
tl;dr preventing spam in the NIP-17 route requires total relay centralization of supposed "spam-free relays" (does such a thing even exist?). Preventing mass deletions in the Concord route depends on having at least 1 special relay in the list.
v2 requires you to at least be a member of the group in order to have any possibility to disrupt it, which I think is the far better option. Now we harden for that case, which requires a great deal less centralization.
Hardening for the NIP-17 case requires exclusive relay centralization, in the sense that no "spammy relay" can be in the relay list at all. In the Concord case it's considered "safe" to have any relay in the list, and you want at least one or two to prevent giftwrap deletion by author - which by the way is already in the spirit of NIP-17.
tl;dr preventing spam in the NIP-17 route requires total relay centralization of supposed "spam-free relays" (does such a thing even exist?). Preventing mass deletions in the Concord route depends on having at least 1 special relay in the list.
2