It is exactly the same thing your own body makes…
The problem is you can’t really revoke shards.
I’m looking into using SEs for Nostr key storage.
there is one, where both nodes die
SCBs only tell the other node to force close
otherwise the channel is dead but can be recovered with cooperation
Bitcoin development being easy enough for anyone to do but hard enough for almost everyone to fuck it up was the worst thing that happened
Many OSS Bitcoin projects are of garbage quality, have security holes and solve nothing
By only being a “cypherpunk” for the purposes of getting a bigger following
Like already happening here
FoundationDB is peak testing-driven development.
The entire thing is designed to run in a reproducible simulator.
Adding an intermediate hop is always higher latency, and ideal != what commonly happens
Encryption also increases event sizes (base64 encoding)
I need to do that for a few projects :)
But I do a lot of verification and manual testing + making the code actually readable. Doesn’t scale too much though.
The protocol can be significantly reworked to allow direct connection between feed provider and client (reducing latency) and add certain things like pagination etc
Doesn’t need to be bound by event size limits either, and improved privacy
it is not really complicated
this is for realy protocol btw not nostr clients
I am working my own alternative cache server. Replacing crappy DVMs and the buggy protocol that is with proper algorithms too
Unfortunately, no. Compute limitations are starting to be rapidly hit, and AI inherently cannot be “intelligent”.
they had to last-second hack together Postgres support
Uses SQLite with no way to scale, and bad schema, nothing can go wrong
and also centralized
also, have subscription (new events) separate from request (stored events)
spec is very simple
disable buffering on your proxy
Content-Type: text/event-stream
each line has a prefix + data (followed by a newline), like so:
prefix: data 1
prefix2: data 2
two newlines = end of message
types:
- event: once per message, defines event type
- id: event ID to be given to consumer
- data: data for event, multiple data lines can exist (they are joined by newline)
- retry: send by itself with nothing else, number in milliseconds to try to reconnect after connection loss