Clarify closed/private, add hidden to nip 29

[staab]

This PR:

• Redefines closed to mean "unable to write". This is not backwards compatible, but IMO the old behavior doesn't make any sense and supports no use cases, while read-only groups is a real use case. I have the feeling that this was intended all along, but correct me if I'm wrong and I can add a new tag instead.
• Adds hidden groups. Relays should not serve metadata or members events to non-members.

@fiatjaf @verbiricha

[fiatjaf]

In current "closed" groups you can't join automatically, you have to be added manually by a moderator or join with an invite link, but you can still read.

In current "private" groups nothing is served by the relay to non-members, so it's the same as you have there as "hidden".

Or not?

[fiatjaf]

Now I see what you really want: a group that is private but that people can't write to.

That's the only use case not covered by the current set of settings.

In that case I think it might be better to add a "read-only" mode instead, which can then be combined with "closed" and "private" to achieve what you want.

Or maybe, if we can agree on it, define some basic "capabilities" that each member role can have. Like currently it's not clear if a normal member can create an invite link or only moderators can.

We could define a new metadata event kind 39004 that defined something like

• "member" role can: "create-invite", "send-event"
• "mod" role can: everything a "member" can do plus "delete-event", "remove-user", "put-user"
• "admin" role can: everything a "mod" can do plus "delete-group"

Then we just have to establish that a "member" can't "send-event" anymore for the group to become read-only, and at the same time we fix all the other moderation quibbles ever.

[staab]

In current "private" groups nothing is served by the relay to non-members, so it's the same as you have there as "hidden".

Hidden groups also don't list metadata. I would expect metadata for private groups to be visible to anyone, but they have to join before they can see messages posted to the group.

In current "closed" groups you can't join automatically, you have to be added manually by a moderator or join with an invite link, but you can still read.

I think this is useless because the user will know when they click "join group" whether they will be automatically added to the group. But we can keep it if people are using it.

Now I see what you really want: a group that is private but that people can't write to.

I think you mean "public", but yes.

In that case I think it might be better to add a "read-only" mode instead, which can then be combined with "closed" and "private" to achieve what you want.

This would also be fine.

We could define a new metadata event kind 39004

I have already drafted something similar here: #2076

This is different, since it's not group-specific, but it's the same basic idea.

[fiatjaf]

In current "private" groups nothing is served by the relay to non-members, so it's the same as you have there as "hidden".

Hidden groups also don't list metadata. I would expect metadata for private groups to be visible to anyone, but they have to join before they can see messages posted to the group.

Makes sense. We could do that. But don't you think it would be simpler to state that "private" groups can't have their metadata listed instead of creating a new category and increasing the complexity?

I don't think anyone is using this "feature" of having "private" groups be listed anyway.

In current "closed" groups you can't join automatically, you have to be added manually by a moderator or join with an invite link, but you can still read.

I think this is useless because the user will know when they click "join group" whether they will be automatically added to the group. But we can keep it if people are using it.

I don't think anyone is using anything, so don't worry about that, but why useless?

If the group is "closed" the client can just not show any buttons, or clearly inform the user that they need an invite. I don't understand your point.

Now I see what you really want: a group that is private but that people can't write to.

I think you mean "public", but yes.

No, I meant "private", but if what you want is "public", then, as I said, we already have the solution:

You can "bookmark" a group without being an officially recognized member. That makes you a "read-only" member of the group. The fact that you are reading a group without ever interacting with it doesn't have to be notified to the relay and sanctioned in a list of members.

If we already have the solution you're looking for that means we don't have to invent new things, at least for now, and we can postpone defining fine-grained permissions to next year.

[staab]

But don't you think it would be simpler to state that "private" groups can't have their metadata listed instead of creating a new category and increasing the complexity?

No, because I think it's good to have listed but private groups. I can think of a lot of use cases for that. E.g. committees within an organization, where committee business shouldn't be freely available, but anyone can ask to join.

why useless?

Does knowing whether auto-join functionality exists in advance determine whether a user will attempt to join a particular group? I don't think so. Approval processes may vary per group, but if the group is listed, that implies that people might want to join based on browsing the listing, regardless of policy minutiae.

If the group is "closed" the client can just not show any buttons, or clearly inform the user that they need an invite.

This is yet another permutation I hadn't considered. Can't users still send join requests to closed groups and rely on an error message? If they need an invite the relay should send an error back that explains that, I don't know why they would need to know in advance.

You can "bookmark" a group without being an officially recognized member.

I agree with that, and that's how flotilla works (membership only matters if you have to be a member in order to do something). But it's important for clients to know whether users can post to the group or not, which is what I'm proposing closed (or read-only) should do.

Use cases I care about:

• What groups are on this relay? (filtered based on hidden)
• Can I read messages in this group as a non member? (private)
• Can I send messages to this group as a non member? (closed, or alternatively read-only)

Use cases I don't care about:

• Can I send a join request to this group? (try it and we'll send you an error message)
• How long before my join request gets approved? (this policy should be in the group metadata)

The current flags have always struck me as weird and over constrained. But I don't mind if people want them and care about the last two use cases, I just want those first 3 covered.

[staab]

Ok, I just discovered https://hol.is, which supports the current meaning of closed. I yield, and will update this PR.

[fiatjaf]

I get the use case for "hidden" now, I think we should add it.

But I still think "closed" accomplishes the other thing that you want (public read-only groups).

[staab]

I still think closed is overloaded. If I understand what you're saying, closed indicates that:

• Non-members can't post to the group.
• There is ambiguity about whether users should be able to send join requests, or whether membership is handled entirely out of band.

And for open groups:

• Anyone can send a join request.
• It's unclear whether join requests must be immediately handled by the relay implementation, or if manual approval is also ok.
• It's unclear whether non-members can post to open groups. I know different implementations have interpreted this differently in the past.

Decoupling the post/join permissions would make things simpler, not more complex, because it would decouple the two concepts and define stuff that people are just guessing about right now.

• closed/open would control whether people should expect join requests to be honored (either immediately or eventually)
• public-write/private-write would control whether non-members can post to a group
• If anyone wants it, we could add autojoin to indicate that join requests are automatically granted ( personally have no use for it)

This isn't exactly backward compatible, but I think it's the closest we're going to get given the ambiguity causing implementations to diverge.

[fiatjaf]

Looks good to me.

[wcat7]

I think “private” is also misleading — it intuitively suggests encryption rather than access control. Something like “private-read” or “private-write” would be clearer.

[staab]

I think “private” is also misleading — it intuitively suggests encryption rather than access control. Something like “private-read” or “private-write” would be clearer.

I agree with that, but I want to avoid changing existing tags if possible.

[staab]

This is implemented in flotilla and zooid