Nostr Web Client

I'm not sure if nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 intended this when designing the protocol, but it affords use cases that do not depend on a remote api. and that is really useful. the protocol dictates a uniform query interface that doesn't necessarily depend on location. so this enables local-first apps with optional remote replicas.

not *needing* an api is huge. the query language is the universal api. this means a local app would work exactly the same as one with data stored on a remote relay.

you *do* have blocking write confirmations, I added it to the protocol in the form of command results (OK). you just don't have transactions, but that can be implemented at a local layer before replicating.

I imagine building a distributed transaction model would be complicated, dbs like tigerbeetle and foundationdb are very complicated. the only other project I can think of tackling this in an interesting way is https://simon.peytonjones.org/verse-calculus/ via a deterministic logic language for building data models in a metaverse context, but that is also complicated.

nostr avoids this transaction complexity by an append-only graph style way of coding apps... if you ignore replaceable events, which I very much try to do at all costs, except where I can't at the moment (profiles, contact lists)

semisol 5mo ago

There’s also the question of do you need transactions.

There is transactions for consistency, and there’s transactions to ensure correctness of the system state (like indexes)

Many Nostr use cases actually do not need strict consistency. There is only some level of correctness required.

CRDTs and conflict resolution fixes this. A notes app for example can be represented as a set of diffs on top of each other, and two updates to the same note can be merged.

This is also why Dynamo and eventually consistent databases exist. You could also have slightly smarter relays that can do slightly smarter queries if you want.

Reply to this note

Please Login to reply.

Discussion

WasBuddhaMaybe 5mo ago

Hi semi

Nuh 5mo ago

I am too familiar with CRDTs... they don't generalise and more importantly they are very hostile towards deletion and storage reclamation as each deletion has to forever take space, the best you can do is what the Willow project does (deleting entire folders with one tombstone)...

Then of course migrating to other hosts or just backup becomes an optimistic operation where you can never know if you are done.

Seriously the only downside of authenticated data structures is that you have to block concurrent writes to serialise them, and I think that is such a simple thing to ask I don't understand why resist it.

Even Negentropy (Range Base set reconciliation) has now been proven to be trivial to do with any authenticated data structure with normal hash function (by the author of RBSR).

So I am constantly struggling to understand why not accept the limitation we accept with LMDB, and we know in our bones that it is worth it.

Nuh 5mo ago

I also want to note, whenever I am arguing about design decisions I don't talk about Nostr usecas, I talk about the general usecase of web 1.0 (excluding Web 2.0 with its aggregation and indexing, because i am skeptical we can fix that).

So when someone smart says that the cloud is a shitcoin, my reaction is, hold on why go that far? Servers are cool, people like to know their data is safe? Why give up on these parts of the web usecases? Not everything is a broadcasting app, we need data integrity too.

jb55 5mo ago

i mean there is no shortage of cloud bullshit. the local first, distributed app idea is criminally under explored. mostly because of the web which heavily encouraged the client and web server model of app development

semisol 5mo ago

remember couchdb?

Nuh 5mo ago

It is not criminally under explored, there are tons of work done on that side of the equation, almost none leveraged by Nostr so far, for example I haven't seen anyone working with Automerge or engaging with the ink and switch people, most likely because all that ecosystem has little to no intersection with Bitcoin.

But these are not mutually exclusive concepts and giving up on open data stores is a step back from the old days of Email and WebDav... why take steps back?

Niel Liesmons 5mo ago

Lol, you keep dropping interesting tech I've never heard of.

Happen to have a list of Nostr-conpatible tech by any chance ? 😜

semisol 5mo ago

Your following list seems to have gotten nuked.

https://nostr.land/restore

Niel Liesmons 5mo ago

I did that all by myself sir #bigboy

Niel Liesmons 5mo ago

Don't use it anymore.

semisol 5mo ago

Lists?

Nuh 5mo ago

Seriously this is one of the things I enjoy doing; connecting ideas across communities.

I had luck with Range-Based-Set-Reconciliation/Negentropy (I guess because people trusted Strfry developer, fair enough), not much with the rest of my suggestions :D

Nostr is not special, anything that people tried for local first and set reconciliation and "bring your own background" etc. applies to Nostr and any open web protocol.

Fun fact, Peergos is based on Cryptree which was developed like 15 years ago.

There are very few new ideas, just ego preventing us from using old ones.

Niel Liesmons 5mo ago

> There are very few new ideas, just ego preventing us from using old ones.

:scoresoccer:

Niel Liesmons 5mo ago

Looking into Peergos rn.

Trying to see how it can map onto private Nostr events and groups.

Niel Liesmons 5mo ago

Where do you work currently btw? If its not Synonym any longer.

jb55 5mo ago

A handful of projects noone has heard about and not related to data-interoperable, local first apps is still criminally under explored to me. You keep referencing webdav like it isn’t the worst possible api in the history of apis… happy to leave those behind.