mleku @mleku - 22h
been making a bunch of revisions to https://protocol.realy.lol - my "reimagining" of the nostr protocol still some ways to go before i'm finished revising the message format and i've realised that i need to eliminate message headers for requests with actual RESTful HTTP paths, because these headers on the requests are really redundant if they are tied to a specific "endpoint" REST doesn't say anything about the use of push-enabling websockets, so it's not quite a REST protocol but for everything that fits that model it's REST at some point in the day after i have done a bunch of tedious work these days and caring for my kitteh i feel the need to completely break from the routine so i'm going to play some more immersive game than the kingdom 2 crowns i play in between bouts of nostr and work on this stuff i think i'm getting better at managing two separate streams with my work stuff (did a little bit on it today) and my pet project/#gitcitadel related work lunch is coming up imminently also, and partly i am becoming aware of this because i'm feeling a bit antsy and my cat is now eating the last bit of beef chunks left in his bowl... i might put another piece on #realy is pretty much at MVP grade for me now, late beta, and it needs a big code review and refactoring but nobody's paying me for that and it works and is giving me a direct personal benefit in combination with https://jumble.social #jumble for having better control over the social comms in my life life is getting better i'm sure it will continue to get better, also, because i'm listening to the feedback
Rise of the Tomb Raider, i decided
haha, fiatjaf reacted to this note with a red flag emoji lol, you think i'm up to something bad after working for over 14 months to build a relay properly that now actually fully works but mainly because you clowns fucked up the whole auth implementation (not you personally fiatjaf, your implementation is actually pretty much correct!) no, i'm trying to make this architecture accessible to more developers and eliminating the confusion so we get some COMPETENT CLIENT DEVELOPERS in here
mleku @mleku - 21h
because you, pablo, hzrd, and others couldn't write a stable and correct protocol client if your lives depended on it, and you have been coddled
also, you are now read only on this relay for such a pathetic attempt to intimidate me
mleku @mleku - 19h
no, it's mainly a refinement that eliminates most of the flaws and makes avoiding these errors easier in the future i have started working on adding it to my relay but this repo is where the main work is going to go to keep it in one place it doesn't change the fundamentals, just puts lines between the things that were blurred and these blurs were the cause of huge problems eg, nip-98 auth could be THE auth, because all websockets start as http requests, so why have this other confusing shit why would you not want to gate endpoints with auth? because you are a big corporation with shitloads of money to lose on spam? yeah and why do we have one path to receive messages when we could separate the protocols with HTTP paths? oh and so on there is a huge number of obvious errors in nostr for anyone who knows how protocols should work and i more or less learned a lot about it because up to 14 months ago i never did any http stuff
i mean, yes, it could be stand alone but what i have in mind is that this event format and protocol are built so that existing relays just live on `/` and this protocol uses everything else, eg `/event` `/subscribe` and so on none of it collides with what already exists, but i haven't thought through how to allow legacy clients using legacy protocol to see new format, or vice versa, i need to think about that... mainly it's just a matter of encapsulation in the forward direction but the backward direction is gonna require a NIP and i think that is gonna hit a lot of resistance
forward compatibility is always easy, backwards not so easy anyway, it's just a matter of building out a few clients that use the new protocol, and there's lots of reasons to change the way it's done because light clients like ebook readers often can't do websockets, and this was a big part of why specify that unless an API requires subscriptions it doesn't need websockets the client devs anyway need to leran how to architect and modularise their code anyway so, i'm just gonna push forward to build out new stuff that uses the new protocol and i know i have people who will adopt it due to its greater simplicity probably better i just the forward compatibility (old to new) problem altogether
