ExploreTrendingAnalytics
Nostr Archives
ExploreTrendingAnalytics
Freakoverse4d ago
So it seems like things could work with NIP-29 for me (and others?) to build on it, but a bit of changes would be needed in my opinion: I don't see how it's good not to have a link to the practical (actual) creator of a group. The relay can remain an 'action' authority, but the creator needs to act as the higher/'actual' authority as a link of sorts. Meaning I'd publish the creation event (mandetory, not optional, and if privacy is a concern then a deterministic derivation from the creator's pubkey can be used) and whatever i change with the rules, or who is allowed to change the rules (admins, moderators) is published by me, and the relay enforces them. This gives a proper view of who controls what, and it would be visible if a relay misbehaves / becomes malicious (if the relay changes the rules and does other enforcements that they creator did not publish, then it reveals for everyone that the relay is misbehaving / is malicious). Regarding the d tag, it shouldn't be <host>'<group-id> but rather <creator-pubkey>'<group-id> where relays must not create a group without seeing a creation event with that same d tag published by the same author as <creator-pubkey>, this prevents a malicious user(s) from preventing a creator from migrating their group from one relay to another because of d tag colision. The cost of doing this, however, is that it would not allow the functionality of forking a group, but that can easily happen fixed by adding a tag to tell relays "this is a forked group, so grab grab posts with this d tag as well". With that in mind, the h tag would also have to have the <creator-pubkey>'<group-id> value. Considering the removal of <host> from the d-tag, we'd utilize the order of the r tag to identify the current relay authority, if that even matters, where we can just have multiple authorities ("enforced") considering that we'd now have the 'actual' authority being the creator. That [private] part is a protection from the general public, but not from the relays, so the solution here is tree encryption / mls-ish (optional). No new kinds, just tweaking the flows and assumptions. This gives power to the user/creator, while complexity and processing remains with relays and enforcement remains on the relay side as well, and there wouldn't need to be a 'migration' because of this anymore, you'd just add/remove relays from the creation event and rebroadcast events. To me this seems like the best of both worlds, but perhaps i'm not seeing something or have misunderstood aspects of it. Thoughts @7fa56f5dā€¦751ac194 @fiatjaf @Niel Liesmons ?
šŸ’¬ 4 replies

Thread context

Root: c85bd26f4119ā€¦

Replying to: a4a58cfff0e0ā€¦

Replies (4)

Niel Liesmons4d ago
More or less what we do. Yes.
0000 sats
Niel Liesmons4d ago
Make it work for multiple content types first. With community moderated comments on all of them. Then see if you even need rooms. We, for now, do not. So the ID = the pubkey.
0000 sats
fiatjaf4d ago
The "d" tag doesn't include the relay, only the group identifier. The relay is implied from the context (where you heard about the group, to what relay was it linking, etc). I think that should remain like that, makes migrations very seamless (again, not implemented yet, we'll get to that soon). The group creator is already exposed, although that's not mandatory, there exists a "create-group" event, and whoever published that is the creator. In any case for most groups it will be clear who is the creator because he will be tagged as an admin by the relay (and in groups smaller than 1000 users it will be obvious that he is an owner regardless of anything) -- of course that won't be true if the group has forked, but in that case I don't know if knowing the creator is still relevant (still, the "create-group" event should probably remain there, although we cannot enforce that it won't be deleted). I don't like having huge link to a group, because public keys are huge, but I'm not opposed to having the public key added to the "<relay>'<identifier>" address, and I'm not attached to that format either, maybe add just a prefix to the public key? I don't see how that helps anyone though. But can't you also imagine a group that doesn't have a master public key? Maybe the group is an equal partnership between 3 people, they own the group together, it isn't clear who is the "creator", and it shouldn't be? Or maybe the group is owned by an organization, but the organization doesn't have a public key, only people who act on behalf of the organization have, so they're granted temporary admin powers. Maybe the creator died, in that case having the group attached to him would only be history, not useful in practice. I don't know, I guess I just don't understand why you're so attached to the idea of a group having a specific owner written in them.
0000 sats
fiatjaf4d ago
About the private stuff: I do think doing some kind of MLS or Signal on top of NIP-29 is a good idea. I didn't try to do it because it would be too much for me and because I think "soft-private" is fine for most cases. But if you're interested in doing "really-private" I think it would probably work pretty well on NIP-29 because it would be efficient. Probably something like leaking the metadata to the relay but encrypting the contents with a shared key for much more simplicity.
0000 sats