Why Nostr? What is Njump?
2024-09-26 10:34:12

pippellia on Nostr: all good questions, reposting for visibility cc: PABLOF7z hodlbod fiatjaf ...

all good questions, reposting for visibility

cc:
quoting

1. Relay = Community?

If spinning up a relay is getting easier and cheaper by the day, why can’t the relays literally be the group/community?

Then:

  • Any relay is by default a public community. The more restricted read- or write-access is, the more it becomes a private group.
  • Any publication targeted at (h-tag) and stored, and thus accepted, by a relay can be seen as a publication in that community.
  • All-in-1 hosting solutions (integrated blossom servers, lightning nodes, …) are made easier.

2. Why invent new kinds?

Why can’t Kind 1 posts that are targeted and accepted by a relay (i.e. community) just be the forum-posts of that community? Why create new kinds for this? And even weirder, why create a new kind with that exclusively serves as a reply to that new kind? Why not just use generic replies (kind 1111) and take the #otherstuff (event kinds and apps) as an opportunity to introduce those?

For chat messages, however, I get it. You need a kind + reply-kind for those.

3. Community VS Private group

It seems like the only distinction you really need, both for the user and the apps implementing all this, is:

  1. Public Community: anyone can read and follow this community but for writing the admins can set limits (pricing, white listings, …)
  2. Private group: only the profiles that even know this relay (i.e. group) exists can interact with it. Read-access has to be granted (invite, pricing, …) and admins can set limits for writing too. Beyond this distinction it’s a bit naive to try to categorize them. Open vs Closed doesn’t really mean much for example, since technically all groups/communities set limits and are thus closed. It’s more interesting to look the ways in which they can be closed and build on the simplest distinctions you can make there.

The difference between Public communities and private groups is the most important one because they both have very different UX and specification requirements:

Memberlist

Communities: None existent
Anyone can read and follow. It just has limits on who can publish what, when. So the most interesting thing to surface is probable something like a list of most active members or a highlighted set of profiles that have special characteristics within this community (top supporter, god-mode, resident artist, …).
Private Groups: Necessary for it’s existence
The whitelisted npubs for read-access are the members.

Moderation actions

Both types of groups need a way for the admin(s) to:

  • Block/remove users
  • Remove events
  • Edit metadata (name, description, guidelines…)
  • Specify who can write publish what, under what condition

Only private groups need a way for the admin(s) to:

  • Add/approve new members → specify who has read-access, under what condition

Generalizing too many actions like add member, join request, etc… that are only applicable to one of these categories just creates bad UX for the other one. You don’t “add a member” to a public community. People can follow it without asking anyone’s permission (ok yes, some will AUTH for reading but that’s besides the point). Some of its followers will then just choose to publish something there and the admin either allows them or not.

Having a common protocol for specifying the conditions for this write-access interoperably (as mentioned above) is what I would like to see instead:

  • Both Communities and Private groups need it anyway
  • You have to assume admins need granularity in the conditions they set for publishing in their group/community: Who, what, under what condition, …
  • You don’t want to link out to custom websites (or similar) explaining their allowance schemes

Sidenote: we need a similar kind of spec for the services that allow you to spin up your hosting solution (relay, server, node, …) so that, when you click “Create new community” in an app, those services can be surfaced. With their business models (including options to self-host parts of it) just there, in the app, without linking out. Same for the lines of communication and payments that are needed to make those business models work from within any app.

Publication and Discovery

Only Communities allow for the exciting possibility of publishing something in multiple overlapping communities at once. Someone writing about how Bees are Capitalists can target their article at the communities that most overlap with its content (and with the author’s means and write-access of course). Members of a community around beekeeping can organically discover content and communities on Austrian economics relevant to them.

With Private groups publication happens only in the group and discovery is blocked on purpose.

Author Public Key
npub176p7sup477k5738qhxx0hk2n0cty2k5je5uvalzvkvwmw4tltmeqw7vgup