Slightly harder to migrate, but I think that's a feature. In the current spec, I have a "federation" event that relays can publish (and use independently of groups) in order to host another relay's notes.
Cons of relay as groups:
- Higher barrier to entry for groups (I actually think this is a good thing)
- Weak security — you don't get any of the neat stuff that encrypted groups give you. Although you do potentially get deniability if relays strip signatures.
- Might be slightly more foreign to non-technical users to adopt
- Implicit policy means functionality will always outstrip interface. Again, I think it's a good thing, but it has its challenges, since clients can't always know whether an event is going to be accepted. Error handling becomes very important, and isn't always the best UX
- Relay-based groups sort of preclude alternative transports if we ever wanted them.
But these are all minor, and can be overcome or worked around.
Thanks for the answer:) Is there a nip?
https://github.com/nostr-protocol/nips/pull/1589
But I'm moving towards compatibility with NIP 29, so take it as a historical artifact.
Are you suggesting NIP-29 should support both traditional nip-29 groups and relay-based groups? These seem like fundamentally different concepts. Aren’t they?
> compatibility with NIP 29
How?
Oddbean new post about login | logout