I know some encryption theory and math from my classes. Different sorts of hashes and encryption standards, etc. But not very advanced stuff. Simple scripts.
I know more about database securitization stuff like archiving, masking, anonymization, shuffling, etc.
i wish more of the nostr devs had this level, or the high level view that makes it clear that we have a big problem with relay development... but hey... it takes someone coming in from outside, after years of working with encryption and elliptic curves to see what is going on here
idk what to do about these things but that's why everyone writes me off as being over the top about it all
and yet still where is our nip-42????
stop me if you remember me talking about NIP-42 before
please remind me also how many clients actually support it? anyone other than nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 and nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn ???
Theoretically, Amethyst. And maybe Gossip?
Freerse has plans to implement. Same with Nostrudel.
it's just signing a special type of event and a different envelope, it's really not hard, the spec has existed, and fiatjaf's implementation has been out there for maybe 6 months now, it's just a matter of priorities... nostr:npub18kzz4lkdtc5n729kvfunxuz287uvu9f64ywhjz43ra482t2y5sks0mx5sz sorta gets it but doesn't get it that relays need to all start implementing the capability... idk if he's open sourced the strfry sprocket for it but the lack of reference implementations on the relay side is a big problem too
khatru can already do it tho...
One does not simply "implement NIP-42". Clients must decide to auth or not auth depending on the context.
Clients should not just authenticate with any relay that requests auth from them for reading public notes, for example.
They should authenticate in order to read DMs, for example, or other special-purpose activities and relays.
i know, i already did this, thanks for your stellar base to build off
currently it doesn't enable the ad-hoc scheme of composition you designed but i will be putting this back in, right now just focusing on making the #layer2 integration with a secondary event store smooth so we can get the last tranche of our grant funding and keep being employed 🤣
also, no, it's not up to the clients when they decide to auth
that is the relay's prerogative and the clients have to account for all reasonable conditions
I've also never worked directly on an event store type of thing. Just used something that had one. So, that's new to me.
Only used RDBs, NoSQL, Object DBs, etc.
well, you got part of it... building interfaces to nostr relays is not gonna be that complicated, you maybe have seen fiatjaf's eventstore repo
my personal pet project would be to build out a pnyxDB cluster back end... pnyx is very scalable, 200 replicas with fast convergence, it's better than anything proof of stake shitcoins use, and it's built on Web of Trust
https://github.com/technicolor-research/pnyxdb
i've been watching this idea develop since 2017, used to be called "SporeDB" and now pnyx as in the hill of democracy in athens, i see blossom as being a good option for raw events but pnyx could build out a distributed index for search
