Replies (45)
You're not alone in thinking that:
@npub1raus...dees
Turns out relays are a great abstraction, infinitely flexible and easy to use and reason about. Relay feeds and other types of custom relay usage could be the thing that differentiates Nostr from all other Twitter clones and are vastly underexplored today.
One example that does one form of "curation" today is
View quoted note →
Try also wss://algo.utxo.one, but we need more!
fiatjaf
One easy solution would be
https://nips.nostr.com/18#generic-reposts: a publication pubkey would repost specific events from other people. In fact that reminds me I should support that on narr and noflux, should be easy.
But I've seen that question come up many times and in my mind the ideal solution that composes better is specific publication relays. A publication would have its own custom relay (well, just its website would act as a relay too underneath, like fiatjaf.com does) and everything you could found inside that relay would be part of that publication feed. The events could have a NIP-70 "-" tag to tell all other relays to not rehost them so articles written by someone for a specific publication wouldn't be found in that person's normal feed (or they could choose otherwise, of course).
Jumble is really a great client for this experience.
One thing I’m unsure of though is the access to articles. You already thought of this with the “-“ tag but I’m curious how that would work in practice. What guarantees brands need to support themselves financially.
Would love to work this out and onboard a publication (and it’s contributors) this way
there is no guarantee at all, "-" tag tries to go against one of nostr's strengths which is censorship resistance so it shouldnt be relied on.
So there are no “pay 2 read” relays? Only “pay 2 post” right?
So business models will have to account for that
there are "pay 2 read" relays, but putting posts behind a paywall is the tricky part of it. the true value you're paying for in that kind of relay is the curation and anything else they may offer
https://zapbox.fiatjaf.com/ is kind of pay2read.
If someone is browsing your relay directly instead of just specific notes or specific pubkeys you can also serve ads by just hosting them as notes.
There is no guarantee of anything anywhere, much less on the internet. Most good faith relays will probably respect "-" (and currently all the big ones do), but "piracy" exists and I'm not even saying that's a bad thing.
I don't believe in "intellectual property" myself, but "-" is not (only) for preventing copy, it's for making intentions explicit and keeping content and boundaries organized, which benefits everybody most of the time.
i get that, but i feel like nostr is one of the last options you would consider to host your paywalled content considering how the portability of data seems to be designed at its core.
and eventually the goal is to have more small relays and less big ones in favor of the outbox model, so in this sense i think the decision of taking "-" into account will be for users to make, not big brother relays.
so yeah i don't know if most people will respect "-", it seems like its never been easier to relay signed data though.
Enjoy it 🤗
Yeah there’s a lot of open questions. Given certain limitations, maybe publications should be just a profile, and maybe they need a new note type that allows for “multi-sig” notes to include the authors and editors.
Or maybe publications see the “anti-censorship” angle as a benefit and just adjust their monetization models accordingly. Either way it needs exploring with real publications with existing business models.
This has been on my mind since I asked that question, because extending my blog software with support for publications is still my goal. However, after observing and dabbling in Nostr dev and specs for about a year now, I'm more convinced than before that relays are the wrong abstraction for publications. I haven't engaged in more discussion yet, because I was both trying to solidify my understanding of why, as well as come up with and implement what I think is a decent event-based solution.
That said, I think relays could be useful for indexing/curating publications themselves (while users should also be able to index/curate them separate from relays). Either way, demo and article incoming (soon-ish).
Are you think publications should be a keypair but then articles within publications should be a “multi-sig” note of some kind?
I think what you describe can still maintain the “locality” of relays. Relays as “places” abstraction is powerful
No, I think multi-sig is overkill. Relays are places, sure, like you can hand over a newspaper on a town square.
I always disliked this idea that relays are good abstraction for feeds... running an entire server just to serve one feed is wasteful.
Let CDNs do their thing, and allow anyone to author feeds that are easily readable with data integrity.
Servers are hard and should be done only once, uploading and updating lists once you have servers is super cheap.
View quoted note →Cc
@Silberengel
Where can we find the most current approach of project Alexandria?
You mentioned that the nip repo does not have your current nip hosted
Good question. I'll update the wiki page and post a link. Liminal also asked for an update.
I'll wait for you to solidify your understanding, and maybe I don't know what a "publication" entails anyway (because I have no experience with that) and that specific thing is better done with a dedicated keypair or something, but that doesn't change the fact that relays are the unique Nostr superpower (and that we don't have any other superpower, so we should use that one wisely).
In other words: if relays are not the right abstraction for publications I'm interested in learning what new things relays are a good abstraction for -- and how these new things can be better than old style publications.
A relay is a printing press, not a magazine editor.
Yeah, I've thought that many times too. Like imagine if these "random relays" to the right were all magazines instead:
On second thought, I think a relay is just a place, as mentioned in nevent below. The relay is the pub where the Inklings met.
View quoted note →The comparison of relays to printing presses is made specifically in contrast to magazine editors. Relay operators are usually developers, and their role is vastly different from that of content editors—they are entirely different professions.
Are you saying Relay becomes publication website ? And the content posted there becomes exclusive ?
Or in other words , you want a legacy website with nostr log in !!! Am I getting it right ??
Please share here as well then. Thank you. 🙏
This doesn't even make sense as an analogy.
But I wouldn't have expected a reasonable take from you anyway given the way keychat deals with relays.
No, you’re getting it wrong
Which one - really becomes a website .. or exclusivity ??
@npub1raus...dees @liminal 🦠 @laoc42
As you can see, multi-author blogs are treated like all publications. They have an "editor" npub and each blog entry has an "author" npub. The type "blog" just causes it to display in the client differently, more like what you'd expect from something like Medium or Substack. In normal publications, the left-hand pane is a collapsible table of contents, and interactions are focused on the index event, but in blogs, the interactions are listed after each entry.
Unlike with simple events, one npub can have multiple 30040 blogs, as they are curated publications and not feeds. And the blog content can be Asciidoc (30041) or Markdown (30023).
Keychat does something wrong with relays? I really like the setup because I thought it just creates a sustainable business model for them
Took the blog feature live, so that you can fiddle with it.
Laeserin
GM Nostr.
I made an #Alexandria screencast on my phone, to show you the first pass at a blog navigation feature, and the rudimentary table of contents. The normal ToC doesn't really work, yet, but if you refresh the page, you can at least see the section headers listed.
We have decided to show the publication card on the Reading View, so that people who arrive there over a hyperlink can orient themselves, and so that everyone has something to ❤️ and ⚡and ✍🏻. (Interactions coming #thoon.)
View quoted note →
is it also already possible to create such a curated publication with your editor? 👀
cc
@Jörg Lohrer
This might be what you are looking for
Yes, curation is key - so it’s the challenge of how to organize it more collaborative
I do it with my #Sybil CLI.
#Alexandria will get the publication editor (it already exists, but we've disabled it) finished, after we get the MedScholar stuff done. We pulled that feature set forward.
The editor is the last thing we need implemented, to get to MVP release.
liminal 🦠
@npub1s3ht...75wz is helping create MedSchlr, a medical and healthcare knowledge base. We want medical professionals, clinicians and researchers to be in dialogue with their readers. We first are going to be populating the instance with publicly available and historical medical research. We hope the #DocChain community can help us facilitate this conversation.
View quoted note →
View quoted note →
Sybil actually has a document parser and uploader, but I haven't tagged it, yet, as it's still very buggy and needs another refactor. My husband is working on the PDF parser.
We're calling it "Scriptorium", for the obvious reasons.
GitHub
Sybil/docs/scriptorium.md at master · Silberengel/Sybil
Test and data migration tool for Nostr, focused on human-legible notes, articles, and books. - Silberengel/Sybil
do you have a link of "schlr" data set rankings for fut. consid.? t Y
@Laeserini'm looking for a shortcut/time - due to constraints
GM, scuze n_n/*****
What do you mean?
what other areas of schlr are peaking interest for thot?
i don't relate well sumx - sry - but do want to try & help the next gen - getGIT gain of knowledge Stella,not 4 mE or $gain{so, there IZ th@]
4 instance; have you thot of smaller data sets that might be easier to monetize? i have been kind-a following this from the beginning(not sure you remember) & have sum thotz*/*
Of course, but those are more specific and we're just planning on helping other people work with them.
t *Y*
