nip29: support for unmanaged groups, top-level relay-local groups and invite codes #1496
Conversation
| Group identifiers must be strings restricted to the characters `a-z0-9-_`. | ||
|
|
||
| When encountering just the `<host>` without the `'<group-id>`, clients can choose to connect to the group with id `_`, which is a special top-level group dedicated to relay-local discussions. | ||
|
|
There was a problem hiding this comment.
here we can add UUID recommendations and why relays may reject some id.
Also, above we defined the id's. here we defined a way to find a group using id and host, combined. which I believe MUST be replaced with names in future.
There was a problem hiding this comment.
UUID is excessively big and unnecessary, I don't think we should recommend it although some people may want to use it.
There was a problem hiding this comment.
We do not plan to use id's for users at all. also on the other hand for example 0xchat is generating very big id's larger than UUIDs.
There was a problem hiding this comment.
I think that is a bug in 0xchat then, and also relays should block giant ids.
|
NIP 29 needed less complexity, not more! |
|
any updates on this?? |
|
I've written my own counter-proposal on #1495 |
|
got it, will check it. thanks. |
…ermissions" into unspecified "roles".
…aragraph explaining moderation.
| ["p", "<pubkey1-as-hex>", "ceo", "add-user", "edit-metadata", "delete-event", "remove-user"], | ||
| ["p", "<pubkey2-as-hex>", "secretary", "add-user", "delete-event"] | ||
| ] | ||
| ["p", "<pubkey1-as-hex>", "ceo"], |
There was a problem hiding this comment.
how can we set admin permissions for each role or admin ?
There was a problem hiding this comment.
Roles are defined at the relay level in my implementation. For instance there are 3 roles.
owner
admin
moderator
There is a kind 39003 that will describe the roles and what permissions they have. That can be used on the client side to understand what an "admin" can do, etc.
Now right now, my relay only supports 3 roles and every group gets those three roles, but at some point maybe we could have roles that could be chosen by the group creator. I don't want to go down this road now though.
On the relay side those roles are enforced on what they can do. For example.
An admin can add-user with role no "higher" than itself. An admin can remove a user with role no higher than itself, etc.
A 39003 might look something like this.
One thing that's not in this PR that I've added is after the role description, I list out the "permissions" that the role has ability to perform. I may or may keep this.
{
"content": "",
"created_at": 1728676272,
"id": "121489f55f3e59db7d60751604a1ba76d3896ea4285fa4c6873ee3d59ebe4523",
"kind": 39003,
"pubkey": "000009056fd123b6a2368f532ec707f9b368c0d1fed62f68be0baeceec776274",
"sig": "a3088ef308a4a6ac73d7144692828001d769652d112cf13e8e724d161c55cfe680f0a883735c23bb87966bb76c3fe9c3d481a9cf3d98ffc4a52aa0efcf442ad7",
"tags": [
[
"d",
"01J9YJ56G6RHSTANHPA2WASDSD"
],
[
"owner",
"Owner",
"The owner role is like god mode for the group",
"add-user",
"edit-metadata",
"delete-event",
"remove-user",
"delete-group"
],
[
"admin",
"Admin",
"The admin role can do everything except remove the owner, delete the group and change owner role",
"add-user",
"edit-metadata",
"delete-event",
"remove-user"
],
[
"moderator",
"Moderator",
"The moderator role can do everything except remove the owner and admin, delete the group, edit metadata and change roles",
"add-user",
"delete-event",
"remove-user"
]
]
}A client could use this to determine what users could do. Again remember, the roles/permissions are enforced on the relay.
There was a problem hiding this comment.
One thing that's not in this PR...
true. that was my point. @fiatjaf need to add permissions somewhere.
|
I really wish NIP-29 was designed for just one application in mind (say... slack XOR discord XOR telegram), instead of a generic group scheme for all event types. In that way, supporters of this NIP could have a fixed scope of event kinds to support and avoid UX issues of some things appear in one client but don't in another. In the way it's written, it suggests that only super apps can code NIP-29 or users will always complain of things missing. |
Im not sure I understand what you mean? It's fairly specific now. There aren't many overlapping kinds. It's quite similar to basic telegram as I understand it. Or at least that's how I've coded my client/server implementations. |
|
Doesn't it have chats + text notes? Those are different things in my mind. There is no reason to require clients to do both in order to have a Telegram client. Separating two and not allowing any other event kind (like a Calendar event, or a live stream) to be part of the group will be beneficial to the NIP. |
kind 11 (text root note) is not a great description imo. As I understand it: Kind 9 chat No client has to support both. You can just support chat style, or you can just support forum style, or you can do both. Nip29 feels very specific to me. I guess it's possible we could separate the "forum style", but I like the idea of a nip29 only client that combines group chat functionality with forum style bulletin board functionality. Also, in the nip29 strfry write policy im working on, I limit the nips quite a lot so that the relay is mainly used for nip29. This is up to the relay operator of course, but I only care about basic metadata (profile info) and nip29 on my relay. |
That's a problem. You can't just find a "NIP-29 client" to use. You have to find one that implements the features you need for a given group. It is very confusing for users. I am definitely in favor of breaking this NIP into two even though the group-management stuff is just copy-paste from one another. |
Maybe so, but I don't see it as a problem at all. I believe most clients will build out all of the functionality of nip29. |
This basically allows NIP-29 to be used without any moderation in normal relays and the usage of these relays as groups. These can later upgrade to fully moderated relays.
It is a counterproposal to #1495.
This PR subsumes #1493.