I'm just thinking relationship statuses for joining communities, nip-22 comments for threads, and a single note for the community anchor/id, name and description to start (addressable event for updating description can come later, its optional).
there's almost nothing to it!
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.
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
Who controls the banner and sidebars if not the moderator of the community?
Does that mean that we need relay-based hashtag pictures and "about me" pages? So that each relay can define their moderation policy on them?
I think calling them the moderator is a bit strong. its just the creator of the community who sets this. they can't really moderate anything except on their relays which host the community. but other relays can host the same community if they want. the banner and description can be overridden later by some future relay-based mechanism if needed ?
but maybe if these are relay based, hashtag communities would be enough. will ponder
There's another variation of this.
Maybe we can take inspiration from usenet here:
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
i feel like anything with multiple tags gets spammy though... hmm
nostr:npub10npj3gydmv40m70ehemmal6vsdyfl7tewgvz043g54p0x23y0s8qzztl5h it’s happening TREX 🦖
If they can't moderate, anyone could use #Amethyst to overpower "my" hashtag into one for porn with crystals.
this is why I sugegsted more explicit community ids vs hashtags. you can of course spam anything on nostr (threads, users, dms). hashtags are an easy target. your niche community? I guess, but these are the same problems we've always had and have methods to deal with (WoT, ranking community notes based on number of friends zaps and reactions, etc).
this is not a replacement for relay group chats, those are still useful for smaller closed communities with low network effects. I'm more interested in a design for open, twitter-style communities.
Why can't we extrapolate the relay group model? chachi.chat is great for communities They have all the features necessary for a reddit style community except threads like posts. Which we can already do on nostr. I really don't see the holdup.
they are closed an invite based... I am trying to build a community approach that would fit into a microblogging app like damus. similar to twitter communities. relay chat doesn't really make sense there
That's really for each individual community to decide right? There can be groups that allow all to join, and I believe such groups already exist in the current implementation
But it’s still relay based no?
I shipped threads yesterday. I would be glad to support this kind of community by just focusing on feeds other than chat.
is this 7D?
Yep.
I think :thread: Threads might be a great way out of the Kind 1 problems.
But why don't we make it solve all problems with Kind 1s then?
As in: why doesn't it solve the actual "Thread" part? Where the publisher gets to publish a sequence of posts in a way that it's clear for everyone where the Thread starts and ends.
You could do this with a kind 30040 index of posts (type: thread) nostr:npub1m4ny6hjqzepn4rxknuq94c2gpqzr29ufkkw7ttcxyak7v43n6vvsajc2jl
But I'm fine with solving this with an adjusted NIP-7D too nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn
I do like that NIP-7D has a subject.
That might actually be good fit too for the Forum solution you were looking for nostr:npub1wf4pufsucer5va8g9p0rj5dnhvfeh6d8w0g6eayaep5dhps6rsgs43dgh9
It wouldn't have MarkDown / AcsiiDoc styling tho.
Different definitions of "thread" I think
I need a clear Twitter Thread solution.
One that doesn't leave it to the apps to magically know which reply to the OP does or does not belong to the Thread.
That's why I see this opportunity.
Pretty easy to add to NIP-7D tbh, without bothering anyone with a different defintion (i.e. Post/Note).
I think it's mostly a UX problem. On the write side, allow a chain of self-replies. On the read side, identify self replies that happen at the same time as the parent and show those as a thread. 7D isn't the right solution, and requires completely different UI, since it doesn't allow for replies to replies.
I want to avoid having all these as different things to render:
- Kind 1 Note
- Kind 11 Post without subject
- Kind 11 Post with subject
- Kind 30040 type: thread (since that would be the only clear Thread spec then)
I don't see the need to reinvent Kind 1 with NIP-7D.
We can just start replying with Kind 1111s on Kind 1 and have the same thing. Especially if no one is using the subject anyway.
> I don't see the need to reinvent Kind 1 with NIP-7D.
We're not, it's a completely different concept. It's intended for use in old-school forum-like apps, not in kind 1 apps.
Within the same community, it's almost the exact same concept.
No, it absolutely isn't. Kind 1 allows for deeply nested reply hierarchies, 7D does not (for example). Clients should encourage longer, more complete thoughts in 7D vs kind 1s, which are context-independent and probably more memetic. It's a different medium entirely.
how does 7D not enable deeply nested reply hierarchies?
+1
(i have not looked deeply at the spec) if you can't have nested replies I don't know if I would use that..
From the spec:
> Replies should always be to the root `kind 11` to avoid arbitrarily nested reply hierarchies.
> should
gottem
SHOULD is being awfully perscriptive here, I don't see why a thread spec would be so opinionated about this?
it immediately prevents it from being used as something like a reddit thread ?
Yes, that's crucial to the definition. I made this because I want a medium that doesn't have deeply nested conversations to enforce participants to stay on topic and contribute to a single "discussion". This has implications for the user interfaces that can be built, and for how people interact on a given topic. This is really the only differentiating factor from kind 1. See flotilla's threads feature for how this looks in practice.
So if they're short articles, then why aren't they kind 30023 short articles?
With the markdown etc... built in.
I don't see how to explain this in-between thing to people.
30023s also allow nested replies, which kind 11 doesn't. In terms of semantics, how is a blog post distinct from a post on a forum? A lot of ways! A blog post is published within the context of an author (or publication), a forum thread is posted within the context of a topic or board. Blog posts are the focal point of the comments, a forum topic is a starting point for a longer discussion. Blog post comments may diverge into different sub-topics of the blog post, forum threads are "on topic" (or, "off-topic" as the case may be). They are entirely different media, and don't need to be squashed together.
1) 30032 should have Kind 11 replies.
2) The only is difference is the target + the limits to who can post the articles there
In the personal blog case the target is the publishers own community, where only he can publish articles.
In the Ray Peat Forum case the target is the Ray Peat Community, where anyone can publish articles.
Same content type in both cases.
> The only is difference is the target + the limits to who can post the articles there
Why are you ignoring me when I say that nested replies is the key difference? This is a key part of the medium.
Because I don't get that part. In the NIP it says you can reference parents.
In NIP 22? Sure, but NIP 7D specifies not to do that:
> Replies should always be to the root `kind 11` to avoid arbitrarily nested reply hierarchies.
Maybe I should have used a different reply kind, but I don't really see why this is ambiguous.
I think we'll just build:
:article: Forums on Kind 30032 and Kind 30040 (type: article) in one feed
:thread: Threads with Kind 1
So far I don't see reasons to have any other content type
I think you should do that. It's ok if you don't understand why 7D exists, you don't have to use it.
Can you prove anyone understands why it exists?
Yep. Great!
Will not use 7D then. That's clearly not my thing.
Totally a deeply nested convo lover, on any content type.
yeah same... I think nip22 supports nested replies just fine from what I understand. just need to pick a root scope/kind
Yup!
nostr:nprofile1qy88wumn8ghj7mn0wvhxcmmv9uq3samnwvaz7tmxd9k8getj9ehx7um5wgh8w6twv5hsz9mhwden5te0veex2mnn9ehx7um5wgcjucm0d5hsz9nhwden5te0dehhxarj9ejxzarp9e5xzatn9uq3wamnwvaz7tmzd96xxmmfdejhytnnda3kjctv9uqzqla9dawkjc4trc7dgf88trpsq2uxvhmmpkxua607nc5g6a634sv57kxvxe what would you think abput using a different kind for 7D replies? Kind 1111 is sort of over-engineered for something so simple
I don't see any difference between hashtags and community IDs. Their meaning is fluid and can be taken over by the crowd at any point. Unless you filter by a moderating relay, which then both IDs and hashtags also apply and the definition is whatever the relay, not the users, want.
They can all be spammed in the same way. The stronger they are, the more spam they are going to get.
there's no difference in terms of spam prevention, its really just to have an anchor for the creator to define the name, banner, and description. if you don't care about those things you can just use a hashtag (#physics) or namespace (!sci.physics.quantum) anchor.
I've always wanted explicit to/cc on notes, so I would throw that in there as well for relay filtering and better hinting:
https://github.com/damus-io/notedeck/issues/788#issuecomment-2734024701
this is a combining my original mailing list idea with communities i guess
also with a user anchor they can also update the description with addressable events, as well as create relay lists for finding the canonical location, etc.
the forking and moderation slicing is undefined and can be grown onto the spec later ?
