Long-form publications

[alexgleason]

NIP-23 defines long-form content, eg habla.news

These posts have an author. But it should be possible to group posts by publication so you can build something like Substack or Ghost.

As I'm writing this, I realize maybe it's the job of the publication to identify which events should belong in it, rather than for the event to mark itself as part of a publication. Maybe as a new type of list. EDIT: or labels

[vitorpamplona]

Looks like a NIP-72 Community to me :)

[alexgleason]

Is that what habla.news is doing here? Seems like a good idea in theory. Not sure they're doing it successfully here.

[staab]

I realize maybe it's the job of the publication to identify which events should belong in it, rather than for the event to mark itself as part of a publication.

I'd say this is the better approach. Lists, labels, or a special-purpose relay could all be used.

[vitorpamplona]

Is that what habla.news is doing here? Seems like a good idea in theory. Not sure they're doing it successfully here.

Yeah, I don't think their implementation is focused on your own Substack or Ghost communities. It's focused on adding posts to more general communities, like "Linux". It's almost like topics right now.

[vitorpamplona]

Lists, labels, or a special-purpose relay could all be used.

For a single author Substack, yes. For multiauthor, then a Community is needed.

[staab]

For multiauthor, then a Community is needed

Not at all, the publisher would curate the content in any of those ways. NIP 72 communities are no different, since moderators have to authorize posts otherwise everyone would be able to post.

[vitorpamplona]

Not at all, the publisher would curate the content in any of those ways.

And if you had multiple publishers, the user has to follow to each individually. The point of NIP 72 is to label who to follow (via following the community itself) so that users don't need to manually go after whoever is the most up-to-date list of publishers of a given substack.

[staab]

up-to-date list of publishers of a given substack

Maybe I don't understand, isn't a "substack" or "blog" a publisher? So even if there are multiple authors, there's only ever a single list, and it's authoritative.

[vitorpamplona]

Maybe I don't understand, isn't a "substack" or "blog" a publisher? So even if there are multiple authors, there's only ever a single list, and it's authoritative.

Sure, but how are users going to follow the substack via Lists or Labels if multiple pubkeys are posting? They would have to download lists and labels for those pubkeys alone.

[staab]

They would have to download lists and labels for those pubkeys alone

I don't see the problem. There are a lot of ways to solve this, either the publisher would publish the lists/labels, and you would fetch those for only the publisher you're interested in, or multiple pubkeys could do the curation and the publisher could make a list of curators. Lists/labels can represent arbitrary tree structures, so you can have as many layers of intermediation as you need.

[vitorpamplona]

the publisher could make a list of curators.

Which is the main thing NIP-72 does. You follow the community and the management of the list of curators/moderators is provided automatically to you.

Lists/labels can represent arbitrary tree structures, so you can have as many layers of intermediation as you need.

Yes, of course, but these are not defined anywhere right now. My point is that NIP72 solves this multi-author dynamic, while lists and labels leave it to be solved by Clients and other structures that are yet to be defined. So, the two options (NIP-72 and Lists/Labels) are not equivalent to each other. They solve different things.

[vitorpamplona]

This is how I see these options:

1. Use NIP-51 for small lists (less than 500 items) that update infrequently. Indexing 500+ items at every update is expensive. The semantical meaning of the list name is owned by the single pubkey.

2. Use unbound lists for more than 500 items or lists that change very frequently. Lists with private names are natively supported. The semantical meaning of the list name is owned by the single pubkey.

3. Use NIP-32 labels to classify content in shared large pools (not necessarily a list) or when the search for the presence of a label is needed. Readers must decide if they trust each key and if each key's interpretation of the label is the same. Specs can guide the use of the labels, but there is no review to verify if labels match their intention.

4. Use NIP-72 communities to manage a set of keys that can classify content as part of the list. By managing the set of keys, you can also manage the semantical interpretation of the curation for the reader.

In 1, 2, and 3, the reader has to manage the list of keys it trusts to provide accurate classification (a classification that everyone in the trusted key set agrees on). On 4, the reader delegates that work to the community leader.

[staab]

My point is that NIP72 solves this multi-author dynamic

I don't think it does, out of the box. Even if the structure technically works, a lot of assumptions about how it works don't hold. For example, Client UIs are still by default going to assume anyone can post to the "publication".

Yes, of course, but these are not defined anywhere right now

This is true regardless of what approach you take, otherwise you end up overloading some concept that already has semantics. The exception is NIP 32, which is intended to be overloaded. But of course, it's best to define label semantics somewhere. Maybe we should just make a new NIP.

In 1, 2, and 3, the reader has to manage the list of keys it trusts to provide accurate classification

All the other stuff aside, I still think you're making this harder than it needs to be. A publication can be represented by a pubkey. So there's no need for complex consensus over what pubkey is trusted, the correct answer is tautological: "the publication is the publication".

[vitorpamplona]

Client UIs are still by default going to assume anyone can post to the "publication".

That Client behavior doesn't make any sense. Ignoring moderators is a choice of the Client, of course, but doing that defeats the entire purpose of NIP-72. Then just use a label. There is no need to use NIP-72 if the client is just going to ignore moderators. The whole point of NIP-72 is to define a moderating crew. Using NIP-72 without it, is like using a sledgehammer to hit a small nail. It works but it doesn't make any sense: there are better options out there.

A publication can be represented by a pubkey.

Sure. As long as the "publication" organization is fine with either:

1. having just only one person managing its article lists
2. is comfortable sharing the same private key among employees,
3. is using some advanced form of NIP-46 to allow other users to manage that key.
4. is using a DVM to allow other users to manage that key. https://github.com/nostr-protocol/nips/pull/1015
5. is adding moderators in a NIP-72 community to avoid sharing any power over the main key.

All of those are viable solutions to solve different "publication" needs.

[staab]

Ignoring moderators

This isn't about moderators, but about authors. Most publications don't allow just anyone to submit an article.

Sure. As long as the "publication" organization is fine with either:

You listed like three solutions to your own objection. Not everything needs to be represented in-protocol. I feel like we're talking past each other here, I'm not even interested in solving this use case anyway. I'm going to bow out.

[vitorpamplona]

This isn't about moderators, but about authors. Most publications don't allow just anyone to submit an article.

Maybe I am misunderstanding what @alexgleason was asking about. I thought a "Publication" on Substack is designed to allow you to add other authors, contributors, reviewers, and moderators, to collaborate on a series of posts with the same topic. Similar to what NIP-72 communities are.

But yes, I agree with you that you don't need NIP-72 communities if all you want is just a single-key authority.

[staab]

Maybe I am misunderstanding the use case then, if it's peer-to-peer collaboration that's a whole different thing, which I don't think any of these approaches probably solves.

[fiatjaf]

I think you're talking about the same author potentially writing about two different subjects, no?

[alexgleason]

I think moderated communities could be a good fit on a technical level. Although I'm not sure it should have the same UI as a community group.

Truthfully, the idea of a "publisher" is a legacy concept. Nostr could imagine it differently. Publishers used to be required to... publish. Now the barrier is 0, anyone can publish onto a relay, and we don't need any gatekeeper.

However, a "publisher" could still create value by increasing exposure. They could put content on a specific domain name, and work hard to create a specific image and build an audience. That's the thing worth capturing here.

[mterenzio]

If you need to grant/revoke privileges to members to add to the publication, it seems like you end up doing something like moderated communities, or else you'd need some other auth gateway/api to grant access to modify a curated list

On Thu, Mar 28, 2024 at 2:59 PM Alex Gleason @.***> wrote:

I think moderated communities could be a good fit on a technical level. Although I'm not sure it should have the same UI as a community group.

Truthfully, the idea of a "publisher" is a legacy concept. Nostr could imagine it differently. Publishers used to be required to... publish. Now the barrier is 0, anyone can publish onto a relay, and we don't need any gatekeeper.

However, a "publisher" could still create value by increasing exposure. They could put content on a specific domain name, and work hard to create a specific image and build an audience. That's the thing worth capturing here.

— Reply to this email directly, view it on GitHub https://github.com/nostr-protocol/nips/issues/1139#issuecomment-2025907147, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAAWDRBCY2ZKSYURYTFKZTY2RSCHAVCNFSM6AAAAABFLQOIA6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRVHEYDOMJUG4 . You are receiving this because you are subscribed to this thread.Message ID: @.***>