Distributed namespaced discussions

[jb55]

trafficstars

We can create non-moderated twitter/reddit-style communities like so:

Basic ingredients

• NIP22 Comments for threads.
• ~Simple immutable, non-addressable note anchor with name, description and banner. note id is the community id.~ We can also anchor on hashtags or namespaces for more generic communities (usenet, etc)
• Relationship statuses for community membership
• optional addressable event for updating description/banner. alternative: relay based banners and description for the same community?

Properties

• can only post in one community at a time.
• separate follow list for communities you’ve joined (- #627 ideally)
• communities have a name, banner, and description and can only be created once (name is immutable, non addressable). communities therefore have a specific sha2 ID which is the unchanging identifier for the community.
• non-addressable sha2 id over d-tag name anchor, otherwise it's not clear which "bitcoin" community you are referring to.
• size of community is counted by number of people who have that community id on their community follow list.
• community posts have a distinct design (shows the community name on top like in X)
• community can have addressable data associated with it via the creator or frost creators (sidebar info like on reddit)
• Since threads could be quite large, we should use NIP-22 Comments, this would allow us to pull large root threads first (if building a reddit-style design)
• outbox: community author can create a preferred relay list for the community, or it can be more amorphous and exist everywhere
• cross sections of the community can be moderated if viewed from the perspective of moderated relays that host content from that community^1
• the community name changing would be confusing, immutable is good for the community creation anchor.
• Description could be overridden with the addressable metadata event, but name can’t change
• there could be forked or hidden parts of the community on unofficial relays. these are just different views of the community associated with the sha2 id of the community.
• they have much better network effects as well and can exist for long periods of time as they can exist on any or all relays
• community members can publish relay lists and they can fight over which views of the network are the "official" ones, effectively forking the community without needing to change the root identifier

Then basically the largest community for a given name would be the defacto “reddit community” for that identifier

Questions

From nostr

d-tag

Q: [email protected]: if the name is the d-tag is immutable... A: [email protected]: i wanted it to have a persistent sha2 id though, otherwise it's not clear which "bitcoin" community you are referring to

what, where and how

Q: [email protected]: Sorry but I am not a dev and I need simple language from the POV of the users. What is a community in NOSTR? Where do you create it? And if I got it right if the community is putting content that does not want any moderation this spec will allow it to be uncensorable even by relays. Do I get it? A: [email protected]: There is no singular definition of a community on nostr. I am proposing one of many alternatives.in this model noone can stop you from posting to a community. the community would exist as notes spread across different relays. there could be a canonical relay list associated with the community, but there could be forked or hidden parts of the community on unofficial relays. these are just different views of the community associated with the sha2 id of the community.

simplicity

Q: [email protected]: how do you assess complexity vs NIP-29 and its' various implementations? A: [email protected]: this serves a different purpose than closed relay communities. they are meant to be large and open, like twitter/reddit-style communities. they have much better network effects as well and can exist for long periods of time as they can exist on any or all relays. community members can publish relay lists and they can fight over which views of the network are the "official" ones, effectively forking the community without needing to change the root identifier

generic/hashtag communities

Q: vitorpamplona.com: Isn't that a NIP-22 with I tags on hashtags? If there is no moderation, I don't think there is a need for picture and about me blurbs as they would just try to drive the conversation to one direction or another. With the hashtag, all the meaning must be extracted by the thing that cannot change: the hashtag name. Everything else is fluid. And it doesn't make sense to remove the fluidness without moderation to enforce a certain view. A: jb55.com: could definitely do it this way, but loses the charm of a reddit/twitter community with banner and sidebar. This could be a feature of the spec, generic or hashtag communities. It's compatible because I'm using nip22

[linear[bot]]

DECK-563 Simple, open, non-moderated communities

[jb55]

cc @semisol, I think you were suggesting something like this a long time ago as an alternative to relay communities.

[alltheseas]

@jb55 how do you assess complexity vs NIP-29 and its' various implementations?

[jb55]

@alltheseas answered in OP

[NielLiesmons]

I see enough common ground with Communi-keys and so far can see it as a loosely moderated version of that.

Having a key pair as the community ID + anchoring it somehow to a fixed "topic" is something i'll happily #interop with.

[vitorpamplona]

I think this is just NIP-22 threads on hashtag Is with kind 10015 (NIP-51) to define which hashtags the person is following.

[jb55]

I think this is just NIP-22 threads on hashtag Is with kind 10015 (NIP-51) to define which hashtags the person is following.

Added my reply to the Q/A on this

[vitorpamplona]

Relays could add more info into hashtags based on what they are trying to curate for.

So, if I follow #soccer in my town's relay, it is about the local club. If I follow #soceer from a FIFA's relay, it's about worldcup.

It's kinda what we already have today.

[staab]

This is basically the same as t, NIP 29 unmanaged groups (but without all the other NIP 29 cruft confusing the issue), and reminds me a lot of NIP 28, which got spammed to death. I think the magic in any of these cases is going to be in the relay selection and web-of-trust moderation. This is also similar to how coracle implemented NIP 72 (ignoring moderation events). I don't know if introducing another method for doing this is going to solve anything, the difficulty really seems to be in making groups either relativistic enough to be build on wot (t works for this, but no one really uses it this way), or in making relay selection unambiguous (this is where I think NIP 29's NIP 51 group membership lists have an edge; they include the relay url for the group id).

[jb55]

There's another variation of this if we take inspiration from usenet:

sci.physics sci.physics.quantum sci.math

then you could break down communities heirarchically

tags for posting in sci.physics.quantum would be:

[sci, sci.physics, sci.physics.quantum]

so you could narrow down into niche areas if needed. no community ids in the case, just nip-22 with I tags

[jb55]

It's kinda what we already have today.

nip22 is kinda important for large reddit-style communities. Is there an implementation of communities as nip22 on something ?

[vitorpamplona]

We have nip-22 on geohashes. But I think I borked the UI (I wouldn't blame NIP-22)... no one is really using it.

The main question is what do you do when sci.physics.quantum gets taken over by the quantum healing folks who love to steal scientific nomenclature to build their scams?

Can we have two sci.physics.quantum communities that are opposing to one another in separate relays? Are users going to get confused?

[jb55]

you could filter that community to your university relay set is one example I was thinking of, where you can only post to those relays if you are a student or teacher.

then you could view all sci discussions on your campus, sci.physics on your campus, etc. anything posted to sci.physics.quantum would show up in sci and sci.physics, etc.

these communities exist at different places and at different times, so it makes sense to not tie them to a specific relay or specific moderators.

you can view just your universities discussions, or a set of all the universities in the world.

lots of possibilities here

[vitorpamplona]

Right, but then you are mixing communities with different management/preferences/rules. It's not just one community. It becomes confusing when 2 users share most of the relay set, but not a few.

User1: Relays A, B for sci.physics.quantum User2: Relays B, C for sci.physics.quantum

In the same topic, in the same thread, user1 is seeing and replying to things user2 is not seeing and vice versa. And that has created several points of confusion. It's like missing chat messages. From time to time, I see users talking over each other but not on purpose, they are just not seeing part of the messages because their relay lists are different. When that happens the sense of community is broken. You don't know which users are seeing what and because of it the idea of a "community", in the most human sense, disappears.

I think that is why our previous implementations led to NIP-29 and strong relay selection for communities. It at least keeps things cohesive for users.

[jb55]

isn't that just an issue of following relay hints properly? you could even be more explicit and have the user say specifically which relays the note was sent to on the post itself:

{
  "tags": [
    [ "to", "#[email protected]"],
    [ "cc", "#[email protected]", "#quantum", "#sci.physics.quantum"],
    [ "t", "sci.physics.quantum"],
    [ "t", "quantum"]
  ]
}

This shows the users intent for the discussion to happen on the MIT community/mailing list

and relays can reject the note if its not destined to them (if * is not present).

In the original proposal where there is an explicit community id, you can source the community authors relay list (you can use the addressable metadata for this) for that community as the to here, and the t would be the community id. something other than t...

[alltheseas]

Say I am a bad actor, and figure out there are public, non-moderated communities. I start spamming said community. How do folks filter out the noise if there is no moderation?

Web-of-trust?

[jb55]

this spec doesn't claim to solve the spam problem on nostr. you can recover a simpler version of nip29 communities with this spec if you have a community id anchor with a single relay hint to your closed(AUTH) or semi-closed pyramid relay. the nice thing about this is that moderation in this case is not defined by the spec, you can have any moderation scheme you want on the relay.

[vitorpamplona]

IMO, Any client-side community assembly algorithm (like web of trust, user's relay list, outbox model, etc) breaks the notion of a "community" because each user is essentially building their own community (or sub-community if the community is too big). We might just call it something else to avoid confusion.

But if there is a common id-relay pair, like a hashtag, event ID, or an address, things change. We can design client-side filters if we know where the actual community is at.

Specifically, Web of Trust is great for reputation building. It doesn't help when you are coming in fresh into a new community. No one will see your posts until senior members of that community start linking you, which could take a while, and become a form of post-approval / moderation of new users.

That's basically how NIP-72 started. Later we converted it to use post approval kinds due to the lack of WoT algos back in the day. Then @staab moved it to ignore post approvals. But WoT wasn't still there. So, it didn't really move the needle that much.

[jb55]

We might just call it something else to avoid confusion

not against that. something along the lines of namespaced discussion groups? not sure what you would call it. distributed discussions?

[vitorpamplona]

How about just enhancing the idea of a regular hashtag, but with pictures and descriptions for them? Maybe declaring which relays to use when following hashtags?

Raw hashtags always felt incomplete to me. They were fine when things were centralized at Twitter. On Nostr they became a mess: you can't really get all posts related to a hashtag from all relays.

[jb55]

the community name can just be the hashtag/namespace. then this can be scoped to a relay:

to: #[email protected] cc: [email protected], nprofile...., #bitcoin@* (or simply #bitcoin, sends to users outbox relays)

then the homestead-community.com relay could have setting for what that banner and description are?

A cool UX here is that when you start typing #[email protected] it could AUTH right away and say if you're allowed to post there before you send.

[vitorpamplona]

The issue with #[email protected] is the dependency on the relay url forever. If the community moves to a new relay, things break/are not as easy to load.

I was wondering about a #bitcoin@npub1.. so that the key itself becomes the community. The key is made from scratch to be the representative of the community (like a Company/NGO brand). Then kind 0 could have all details about it and people using hashtags could point to exactly which definition of the hashtag they want without getting stuck to a relay.

[jb55]

The issue with #[email protected] is the dependency on the relay url forever. If the community moves to a new relay, things break/are not as easy to load.

I was wondering about a #bitcoin@npub1.. so that the key itself becomes the community. The key is made from scratch to be the representative of the community. Then kind 0 could have all details about it and people using hashtags could point to exactly which definition of the hashtag they want without getting stuck to a relay.

could definitely do #bitcoin@relayprofile and have it auto-complete. email-like identifiers are just more intuitive for people. perhaps users could type the email-like identifier and in the note it would get the relay nprofile and put that in the to

[vitorpamplona]

#bitcoin@nprofile1? so that you have a hint for the outbox relay of the key at the time of singing, while also having the key to search for the new outbox setting via NIP-65

[alltheseas]

I was wondering about a #bitcoin@npub1.. so that the key itself becomes the community.

I think this is what @NielLiesmons has been proposing - "communikeys"

[jb55]

so in this setup you could follow global communities #bitcoin o

communikeys

is there a spec for this somewhere so I can compare?

[alltheseas]

is there a spec for this somewhere so I can compare?

I pinged @NielLiesmons. Niel to advise

[jb55]

#bitcoin@nprofile1? so that you have a hint for the outbox relay of the key at the time of singing, while also having the key to search for the new outbox setting via NIP-65

i think relay pubkeys complicates everything too much and has the same problem if the relay key leaks

[vitorpamplona]

i think relay pubkeys complicates everything too much and has the same problem if the relay key leaks

True, but also, any community that uses modifiable descriptors/images can be stolen and taken over. So, I am not sure that is a problem we can solve. Even with NIP-28, which uses an eventId as anchor, things can still change.

I guess we need to choose our poison: either relay-bound (if somebody takes over the relay or the relay becomes evil) or key-bound (if somebody takes over the community key itself).

The key side is interesting because if people want security they can just create the community and throw away the key.

[jb55]

I’m just gonna make nip05/explicit relay urls at the base of this protocol to simplify outbox logic, since theres no real accepted way to get relay lists in a distributed way without nip05 anyways.