the cloud is a shitcoin. we can design apps and systems in a more distributed way when you don't have centralized accounts and backends. the frontend is the new backend. the backend is just the db now.
nostr:note19atfvp2xtyl37mppwxsrfn92tc5km8gpguyyqnuap904n38aw5wsgct7ay
the cloud is someone else's model training on your data.
I don't care, I just wish the training was to learn what's in the data instead of learning how to ignore it
OK so support p2p cryptocurrencies like Bitcoin and Monero and doggie coin instead of the lightning shitcoin that makes users rely on the cloud
Wait, why am I even replying? You have me muted despite the fact that I once used lightning against my better judgment to zap you 48k sats for your work on software I can't even use as a non-Apple fanboy
Lightning is p2p
Kinda like how soulseek "is P2P"
Involving P2P connections, not being a full P2P network
Absolute trash people call "Bitcoin" so it can borrow the name recognition and reputation of an actual cryptocurrency
In my experience it works very well.
So you're relying on a constant internet connection and paying for it with your data and possibly also money too
Yes, I run a home server to be part of the network instead of expecting it to be provided for me.
Miners and nodes get paid, it's not a charity you deceptively-phrasing fuck
Including lightning on your home server is promoting a shitcoin that makes people rely on the cloud
It doesn’t make anyone rely on the cloud. Nodes are easy to run. And what’s the alternative?
The alternative was the whole point when you first replied, people should be using doggie coin if they want fast cheap public transactions or Monero+Tor if they want fast cheap transactions with more privacy
Lightning absolutely makes people rely on the cloud, it's batshit mega insane to pretend everyone can run a node currently
And I don't even see how you'd argue that running a lightning node isn't just using your server as part of the cloud shitcoin Will was talking about
Dogecoin? Are you serious? If I wanted cheap transactions in a currency that’s going to 0 against bitcoin, I’d use Venmo.
Monero is the one that trends to 0 against Bitcoin so far. Bitcoin trends to 0 against doggie coin throughout doggie coin's entire existence.
Maybe you're using childish zoomed-in charts or making some insane future prediction that defies all logic
but even the db is in the frontend. the backend is just a replica of the frontend's local db
You are describing local first apps, however they still need a server to help syncing when p2p doesn't suffice, which is often the case, but that is assuming you don't also need a datastore.
There is only so much apps you can build without a reliable storage for user data, even if that storage is a laptop operated by one of their family... it doesn't matter.
Then if you want to have large search indexes you need centralisation, but at least we shouldn't take a step backwards from WebDav, we should make it better; check Peergos for that, you probably will like it.
a lot of early nostr apps started with server-as-the-only-datastore but now many of us are making nostr apps local-first + set reconciliation with remote only when you need it.
the flexibility of choice here is super powerful. notedeck is local-first by default for any app you build inside it (its a nostr browser). local network or remote syncing is more of a business logic choice for the app.
I understand that, it is not unique to Nostr, it has been a thing since Git, and Peergos for example while it puts lots of emphasis on data integrity using authenticated data structures (as opposed to separate events) it still acts as local first, and tries to sync with the server with CAS like api.
My point is that eventually you are going to run out of apps that don't require a clear and consistent answer to the question "did I update the state yet?" Or "What is the canonical state that others eventually will see".
There is only so many apps that can tolerate the lost update problem, which is very common in systems that don't have a datastors.
My point is; data stores are not a centralisation force, unlike say search indexes and "global feeds", so we shouldn't give up on them, they can be as easy as letting the user choose one of their devices as a home server, and all other devices wait for it to acknowledge updates, and show things in pending state otherwise...
But also, if your notes can be found, then a note about your "Outbox" can be found, and then that home server being cloud hosted is not really a "shitcoin", because you can't exit it on a whim.
the behavior is up to the app to decide how they want the data synced, not the protocol. its true this logic might diverge between apps, but if looking at it on a per app basis then it will work fine.
if cross-app compatibility is important enough (i think it is for microblogging), then we will converge to things like outbox and other methods, but we are not tied to it and its open to be improved even more. its bottom up not top down. its the bazaar not the cathedral.
the SSB, matrix and even git guys already tried the method of heavily perscribing the state syncing in a top-down way, and it just sucks for app development.
I respect that. My experience is usually that devs are frustrated when I put in their hand and API that doesn't block until the data is canonically stored, so I am always surprised when Nostr OG devs argue that something like webdav or S3 would suck... but I guess you have definitely earned your opinion.
I just struggle to imagine what can be done with Nostr that a remote storage API with a tree over the data, just like LMDB would make impossible or suck, for example when I don't want need LMDB atomicity I build my own buffer, it doesn't get in my way.
I would still be interested in learning what would you hate about something like LMDB but with remote api?
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)
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.
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.
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 ? 😜
Your following list seems to have gotten nuked.
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.
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.
So early. So true!
