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.

Reply to this note

Please Login to reply.

Discussion

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?

A group can exist on multiple relays as well and they can just chose to shift on another one in nip 29 IIUC and there can obviously be multiple groups in a relay

But theres so much crap in that spec when it could have just been nip22. I don’t need 99% of it

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.

Yeah, NIP-7D is for Flotilla, not for everyone.

It just kills the feature of NIP-22.

Ow, that's in NIP-7D.

Gotcha.

There's the source of confusion

Scuzi!

🫂

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

If you solve for Threads client-side, than the current Kind 1 is already good enough.

That's what I'm saying

A thread is a linked list. An index is an ordered list.

Twitter Thread = :110percent: Ordered List

(not talking reply section threads here)

Oh, right. They don't link them.