Nostr Web Client

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

Nuh 2y ago

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.

Reply to this note

Please Login to reply.

Discussion

Melvin Carvalho 2y ago

Yeah, so it's just a starting point, and can be extended by the NAVs. Basically when I have an app im using that needs something I'll add a micro spec and library for it.

- range requests - yes, needed for video, I added this to solid

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

- collections, yes will be added in a NAV

- read access control, will be added with WAC

- scopes, not sure on that yet, probably use case driven

- multi key yes, will be added

- e2ee out of scope, dont take on too many things, scale it first

local first is indeed interesting, the design should allow that to happen over any transport, which is the strength of solid, and weakness of all the p2p stuff out there -- else I would not have needed to make it

Nuh 2y ago

> 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.