Right, this is kind of what I mean. You need a site to plug in to Nostr anyway (client, website, app, etc). And the clients send text messages arranged in a certain way to postgres databases around the world. You can do one (client)-to-many (databases) publishing with a click, which is innovative. Now people are quickly relating zaps to posts, which will be like rocket fuel and is very innovative. But we still needs lots of the existing Internet for it all to work (postgres, AWS, ligthning, etc, etc). So I am still wondering about the core of the Nostr idea, I guess.
i also support human-readable URLs using nip-05 + d tag, so you can use d tag as the article slug https://habla.news/verbiricha@snort.social/references now i realize i need to support _ usernames š¹
Discussion
Youāll have so many client options that the average person will not need to worry what to use to write on nostr. Even clients not catered to long form content will do a good job of displaying it. Already working on this.
yes, nostr doesn't negate the fact that we need internet infrastructure, like AWS and databases, etc.
what it negates is the siloing of content; you can't interact from twitter with content in facebook, because, even though it's all powered by the same infra (databases, etc), they are constrained to their own domain.
Nostr makes it so *all* content (not just social networks) can be interoperable.
Nostr superpower is distribution
Right, that's a good way of framing the question. What is Nostr's superpower compared to all of the other stuff that already exists on the Internet? Whatever the answer is to that question should be the focus. For me looking at it over the past few weeks, the answer would be something like protocol level + relays + zaps. That's it, that's core, the engine, the increased flow. All of the value exchange bits need to be hard coded as it were at the protocol level, so that no one client site, now or in the future, can control that either.
Iād add a 4th - experience. Each client can offer a very different experience with access to the same content. While āprotocol levelā covers it at face value, the impact of those experiences might be transformational in and of itself.
Right, but if it's a protocol level core superpower thing, we're talking about, the protocol level needs to enforce its core in some way across the whole, in whichever clients are built for whatever experiences along the way. I would argue the value exchange bit needs to be in that core, right alongside the content message bit. Otherwise different clients will own different ways of doing value exchange and if they have access to the content from one of the relays, perhaps in some manner unintended by the creator, etc, etc. If it is direct reader-creator with no intermediaries necessary across the whole network, that would be big.
Nah, the nostr superpower is peer pressure
Just look at zaps
Which wallet had the balls to say "nah, simple sats are more private and cannot be faked, we'll stick with that"?
Which user had the guts to say "nah, I'm good with my normal LN Address, no need to advertise the sats I send or receive"?
Few
Very few
Donāt strictly need those things, itās the best tool for the job now. Lightning needs a ton of work but is super impressive, the level of improvement that can be done there means it will stay and be integral, clouds and dbs are irrelevant.
This is a hydra. It doesnāt matter what the DB is or where itās running, you canāt chop off all the heads to bring it down nor can you corrupt the money.
No-one can censor your journalism here nor anybody elseās, and no-one can stop you getting paid.
Right, something like that. If the value exchange bit is coded in at the protocol level too, it will work. Maybe even some protocol level way of telling a client that you can't have this note/full note unless your client implements the value bit too. The protocol should enforce its core in some way.
yeah, that's coming
all these functionalities are being built at the protocol level, clients might choose to support them, or not; most clients will probably not support all features and that's a good thing.