No it isn't, any user blocked from the most 10-20 popular relays is done for. Because Nostr refuse to use "complex" solution like Pkarr, and just declare that discovery is not an issue.

I don't know why do I need Nostr if I can do all the discovery with Pkarr, why does it matter that there are more people using Nostr? If Nostr clients refuse to do what I care about? Interoperability is such a red herring.

You will see eventually that Nostr won't help you get a single more dev interested in what they weren't already interest in.

You just joined Nostr and called that a win, it is a win for what Nostr aims to do, but not for the goals of Solid for sure, you still need to do the same work and face the same apathy.

I am very well aware of the appeal, but:

1- I don't have to make Nostr architecture my base just to use free pub/sub. I can just take advantage of it when I need, especially that friction and costs are zero.

2- if all I need is 1-1 relay, then there is also the competition from SimleX, which is definitely more private, so Nostr now is best only for many to many broadcasting.

3- there is only so much I can do with ephemeral data, and I want persistent and more importantly e2ee, nostr is not made for that, and that can't be done without increasing Nostr complexity, ok but whatever data store will hold my data persistently, it can also double as ephemeral open pub sub if ever needed. Especially with pkarr when I KNOW where my contacts store their data and can send them messages there, or fetch their latest public notes.

Nostr relays may very well end up being the RSS of this ecosystem, the aggregators and feed generators that people subscribe to to get a precompiled view, which I feel Fiatjaf is trying to cement as the way to use Nostr and I full agree with that, but it can't be the infrastructure for what I want, not without ruinng its simplicity, case in point, you could have built NosDav over relays, but it would be a bad idea.

I am 100% sure if I did Fiatjaf will fight it because it is complex, like he did with Nip26

I get your point, but just ignoring all the technical limitations (for example relays don't understand what are orphaned nodes to GC it), and even ignoring the overhead of linear size of signatures.

Ignoring all that, whatever I build using nostr events will be opaque and useless to Nostr unless they use my very code, so the excitement won't translate, rather the values of the community will reject the complexity and fight it.

The remaining upside of Nostr is basically free relays with no friction to sign in (albeit unreliable storage), but the moment someone else offer better cloud storage, you are left only with the tech debt of the choices Nostr did.

Case in point, Nosdav has ZERO reasons to support Nostr event shape, or even secp since it doesn't really run in Nostr infra, you are just trying to get Nostr devs interested this way, but I am not sure it is a bet that will pay off.

SimpleX did its thing, and still got biggest Nostr supporters attention.

Maybe you are right, and maybe there is not much money or financial gain in this space anyways, so might as well do what you want to use yourself, and don't worry if it will get devs attention.

Found a way to do e2ee multiwriter key value store, that can be searched and replicated just as efficiently as a non-encrypted one, and synced as efficiently as an append-only log, but allows deletes and garbage collection.

Single rountrip to full sync

Log n roundtrips for partial sync

Log n proof overhead (Nostr is linear)

Authenticated ranges

Really really good.

Combined with a more pragmatic discovery and client-sever architecture, it will stay be order of magnitude more complex than Nostr, but order of magnitude simpler than p2p, so actually manageable and adds tons of features that makes it worth it.

If sovereign cloud hosting is going to be viable, we need sub-linear scaling and we will need e2ee (so relays don't worry about content they host).

None of this is going to be ready anytime soon, but it I am convinced it is worth it.

It is going to be hard to maintain the motivation and getting people to care though 😕

We have one, just give unique names that can't be decentralized and embrace public keys: pkarr.nuh.dev github.com/nuhvi/pkarr

Did you start styling egui yet?

Doesn't it make more sense for vendors to announce their offerings and users just contact them and pay the servers they trust most? Nostr is a good advertisement board, the rest can just be good old Rest API, just define that API.

Even if you want to be a Nostr maximalist, then, users can send the offer to advertisers and pay in advance.

Isn't it much easier to make a reputation system to 10 vendors vs 10000s users?

By the way, if the future of Nostr relays are many many small relays, then the architecture of (Personal Datastores + Indexers/aggregators) is vindicated.

Which is good, many many apps don't need any aggregators or indexers, for example 1-on-1 or small chat rooms, blogs, stores etc.

This is where #Pkarr will really shine, if you want to make a censorship resistant web, then first recognize that most of the web isn't a timeline, in fact, the death of social media might be the best thing that ever happens for the health of the Internet.

It is time to pay attention to efforts like #Earthstar and #Nosdav etc. Or build something else that have enough features to enable almost anything with sufficient control and privacy.

It would be super exciting if this is the age of open web enabled by Bitcoin, first because it popularized mnemonic seeds and key management, but also because it proved that the world is full of mercenaries willing to be your cloud providers without political agenda, and finally because it will make it feasible to pay these folks without permission.

I hope, few years from now, we are all bloggers and digital gardeners again.

The great disadvantage of Pkarr (but applies to any DHT and even to purple pages if it wants to survive) is that records are only kept for an hour and needs to be published over and over, so someone needs to be online and keep doing that.

However as mentioned in the README whoever is hosting your data, is capable of refreshing your records on the DHT, and maybe even has the incentive to do so, if you are paying them to host your data, or for whatever other reason, as long as the cost of keeping your records alive on the DHT is manageable

This is why I made a point to prove that the cheapest VPS ever can still keep 120,000 records alive for a week without any noticeable cost.

OK that was quick, so you mean THE "gossip model" + special relay to find the special events instead of a DHT.

Sure, if you can trust that purple pages relay is gonna last forever and scale to millions of users, then you just proved Bittorrent didn't need a DHT and they could have went with a single tracker.

But if you recognize that you absolutely need load balancing among many many volunteering churning servers, then you need a DHT

So now the question is, should Nostr build a DHT that treats secp as a first class citizen, and have like 10 nodes in that DHT, or use the existing 10 million nodes of Bittorrent DHT and accept ed25519 keys like they accept NIP5?

If you think the latter makes more sense, well, that is exactly what Pkarr is, plus some work I did to prove the viability of the model, not much more.

I need to read that. Will do tonight. But from the name, gossip can only be so good, there is a reason why DNS powers the internet, it is amazing, Pkarr takes that and adds a decentralized root server and signs records so you can get cached records from anyone trustlessly.

But I will check what you mentioned first because I know people use gossip to mean many different things

Just like DNS, it is basically adding DNS records for publicKey, so it would be used like NIP05, you add people by their ed25519 key, and every now and then check their records, if they changed their nprofile you follow the new key and new relays.

If all Nostr relays went down tomorrow, the day after we can discover which relays our friends are using now, if they publish that on Pkarr

As #Nostr grows, big relays will capitulate and small ones will churn, it is time to pay close attention to discovery and local-first (client side storage) + efficient sync to smoothly recover when relays go down without notice.

I built #pkrr to solve discovery, and #Negentropy can be added to NDK fairly easily to sync with #Strfry nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft

> search queries, hmmm, not sure that's standard

Yeah but you decided to conform to the webdav standard in the first place, and Nostr, we can just build something that works good for local first offline first collaborative PWAs now!

Same applies for WAC where the upside of conforming to these obscure old standards are not clear, but force you to make suboptimal choices.

I am a huge fan of standards that are ubiquitous though, so I wouldn't even worry about transport agnosticism, I am happy to go all in on HTTP and REST.

Well, now is a good time because I just got it to work from behind NAT.

Long story short it is a decentralized root DNS server, you can publish any Resourfe Records for a ed25519 public key and anyone can resolve it from anywhere.

Limitations: it is slow so you need to cache it aggressively, and it is ephemeral so someone needs to keep republishing it every hour or so.

```

npm i -g pkarr

pkarr publish

```

Once you are done you can run the pkarr keepalive command, or just give me the key and I will keep it alive for you.

Plenty of work can be done to make it a robust system and add DNS over HTTPs, but I feel getting feedback is as important at this stage.

Fuckin hell! That's impressive though as long as it works, but the lengths we go to avoid opening a port is crazy, meanwhile Bittorrent have been using upnp like there is no tomorrow!

There is still the problem of discovery (when suddenly I don't have common relays with the nsecbunker service provider for some reason).

Using Nostr as a replacement for good old web platforms instead of decentralized DNS (Pkarr) and opening port when necessary, sounds as extreme as using p2p stack and holepunching, just more browser friendly.

I am aware of Nosdav, but I don't appreciate its dependency on Nostr spec for no reason. For example Pkarr HAS to be ed25519 because Mainline DHT is the value proposition and it requires such. Nosdav has no reason to be using (exclusively) neither secp or the Nostr event spec.

But these are the least of the problems, the bigger issues are:

- No search or range queries API (only stores files not kv store)

- No collections/folders or any scopes

- obviously no read access control because there is no scopes to enforce access control on

- no write access control that supports multiple keys on multiple devices, so again inheriting Nostr choices that are recently forced the creation of custodial services like nsecbunker

- no efficient sync with other servers or local nodes (to enable local first and offline first apps) even though Strfry adopted such algorithms after I shared that paper with Hoytech

- while it maybe out of scope, but investments in client side encryption SDK is absolutely necessary to make it e2ee (including filenames) which is important for privacy and minimizing risk to servers providers getting hit by content laws

I love that Nosdav is much simpler than DWNs and embraced REST, but we need to do better, and that we can without much complexity.

If I would use one sentence to describe my issues with it: it doesn't do enough to support local first apps, which is a step back from Git.

Are you opening a port? Using upnp? Or a tunnel like ngrok?

The fact that more and more apps built on Nostr is treating it like a public key based remotestorage.io is a good sign.

If DWNs didn't really suck at shipping, they might have became the standard for per-user backends already, but here we are.

Nostr was designed to be a Twitter alternative and made a lot of sacrifices to reach that, and the nsecbunker (giving your key to a server) is a clear sign of that, it devolves publickeys into a server owned identity.

Let's try again with more focus on local-first apps and proper key management.

For more information check these keywords:

Unhosted.org

RemoteStorage.io

Earthstar project

Solid project

nostr:note1953vnqp347ztrucrkyp3jfgtarnalcxjlxjgl408d8mplwwpljyqsql8k2

nostr:note17fzhzsr5fvmjf0c2kzfp70fsqzm7zl3jeecr9fmmhgja0tjsegyq86vvcn

Always bet on REST