fiatjaf4d agoYour scheme also seems to work at a first glance, but it's computationally expensive and cannot be used to do "private" groups, unless you introduce encryption, then it gets more even more complex and inefficient. I believe a similar approach was attempted at NIP-87 (which was never merged but was implemented in Coracle and somewhere else I forgot and actually used for a while).
The biggest problem with it, though, is that in order to get a consistent view of who is in the group you need someone controlling it. In the most obvious scheme that would be the pubkey that created the group -- or you can come up with something else like a threshold scheme or some form of democracy, at the cost of complexity -- in any case there is always still a group of people that controls everything.
In NIP-29 the group has admins, but they don't own the group. The relay enforces the admin's policies, but if a part of the members is unhappy with the administration they can fork the group and move it to another relay that will pledge to serving them, then the group can continue there. For small friends groups this isn't a concern, but it solves many issues that have happened in big Reddit communities, for example.
💬 1 replies
Thread context
Root: c85bd26f4119…
Replying to: 6a167ca2b11a…
Replies (1)
Freakoverse4d agoTook a bit of time to understand what you said in the quoted post, and I think I understand now where you're comming from regarding the design of NIP-29, where the best management and moderation flows happen on a centralized system, but when other protocols tried to do that but in a decentralized manner, they still end up with the flaws of centralization, but because of nostr's unique structure, it allows the possibility of migration from the original relay to another, in case it shuts down or starts censoring the group. Most other protocols (or all?) can't easily do this in comparison.
I understand the logic of where you're coming from now, and I'm not against it, however... I guess I would be more of a fan of NIP-29 if there was a good flow for migration steps, and more so if there was less dependancy on one relay (so a group would post on 2-5 relays that enforce admin policies) and decoupling the relay address from the group address. I think at that point I'd be happy to use NIP-29.
(and in regards to actual privacy, so not even the relay knows about the content of the group posts, we'd have that tree-based encryption, so i guess no worries there, it wouldn't be that high of a cost even at scale)
Also, yes you're correct that what I thought of (or what Niel linked to) has high processing, where the bigger the group the bigger the procesing needs to be done on the client side and that is definitely an issue. I guess that's the cost of if we want to persue the core nostr flow that has been done for most NIPs and what most people love about it.
(Moderation management with shared pseudo-powers can be done here, but yea, more client-side processing as a result, and full final actual moderation is done by the creator of the group)
I'll explore and think about NIP-29, to understand it more properly but to also see how can it be adjust to improve the hiccups i see in it (addressing the part where i said "I would be more of a fan of NIP-29" in this same post). Basically lossening up NIP-29 a bit more (probably not the correct wording here but i'm hoping I'm understood) would probably make those that don't like it reverse their thoughts on it and embrace it.