Nostr Web Client

Fiatjaf is definitely a strong believer in RPC as superior to HTTP based API.

However, I think this is a week point, you can send HTTP queries over Bluetooth, HTTP headers are not inherently inferior to JSON, i argue it is better, if only because it allows for using curl and all the infrastructure of talking to servers.

I will however agree that a query language that is simple enough, and thanks to Fiatjaf discipline; resistant to creep and complexity is a great feature... but this is not special to Nostr either, nor does it get embedded by a canonical source of truth or a key value stor api.

You can name your keys in ways that make them effectively lookup indexes, which already covers many of what Nostr queries do.

The append only way is also entirely possible in a system like Peergos, and if you ONLY create new files. Then the CAS will never fail, but then you have extra features that Nostr doesn't have, like being able to see exactly what is the current state, and GC older leaves (which is what LMDB does as well) and everything we take for granted when we have a reliable database.

I am not supporting decentralised databases to the contrary, I am supporting a single writer (home server) so that we don't have to fuck around with decentralised transactional databases.. too hard. But the price of that, is a server, usually in the cloud.

My hope is that smart builders stop perceiving that as a bad thing, as long as the migration between home servers is smooth and permissionless.

Either way, I trust that people would converge into that eventually, and we would have something like Proton Drive (but open and self hostable) as the base layer of free web development, especially with decentralised PKI to make migration better than what it is in say Mastodon. I hope I did enough work to enable that.

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.

WasBuddhaMaybe 5mo ago

Hi semi

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.

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

remember couchdb?

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?

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

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

https://nostr.land/restore

Your following list seems to have gotten nuked.

I did that all by myself sir #bigboy

Don't use it anymore.

Lists?

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.

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

:scoresoccer:

Looking into Peergos rn.

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