i guess i could write some useless flowery things about the value proposition that my application makes, that was the initial starting point, but i think you need to experience it and then you will understand it, perhaps. hyper-real-time messaging, or liveposting, or real-time text, what whatever you wanna call it, i've felt there was an energy in it since i first encountered it on a beta of the site formerly known as bw 3 years ago. more or less since that very moment, carving out a little corner of the internet that sucks less has taken up larger or smaller chunks of my excess time. xcvr is what has congealed in the last 6 months of concerted effort.
xcvr is an application that exists both on and off of atproto. it consists of the xcvr appview on atproto, but it also consists of my own lrc protocol, which is where the magic happens, and also where this project has started.
lrc
live relay chat is an application layer protocol for hyper-real-time messaging, which means that it allows for you to efficiently edit your message in real time. you can tell by the name that it's based off of irc, and at this point calling it an application layer protocol is mostly just hot air to inflate my ego; but the whole development ethos so far has been to move slowly and learn things, so it being "its own thing" was born out of a desire to architect something from the ground up to the sky.
lrc started on top of raw tcp-emdash-you can find the original post about it on my blog-emdash-which was ultimately quite silly because i had no clue how websockets and tcp differed, i kinda just figured that 1 write would correspond to 1 read, so as soon as i tried out my first init + insert, i crashed the server, hence the sloppy headers. no way to build from the ground up besides failing a lot and arriving at a worse version of somebody else's solution.
but i digress. that old blog post should still be totally correct, but the highlights are that if we want a protocol to allow hyper-real-time messaging, which means what i see on my screen as i type it out is what you see on your screen, more or less, then we need to be able to start and finish our messages, add to and remove from them, and then whatever extraneous things are necessary for setting and obtaining metadata, and moderation and safety actions.
of course, instead of communication occuring just on top of tcp, it's on websocket, and instead of designing the message structures all by hand, i use protobuf for it now. less romantic, but it gets the job done.
originally when i was making lrc, i was coding it in go, and i made a terminal user interface with all the escape codes done by hand to put the characters in the appropriate places. i would looooove to make a tui for xcvr! i know i need to set aside some time for it because even though likely i am the only freak who'd want this, it's just so essential to give yourself treats to stave off burnout.
xcvr.chat
this is kinda the middle child, the initial foray into wtf a http request is and how do you talk with a server through json, and then how do you read the result in javascript. it's still up, though i probably should shut it down sooner or later, and it has a few threads that will live there forever because there are many bugs, it was really just a proof of concept that i was trying to get out before passover to show relatives to avoid the shame of dropping out of school.
so xcvr.chat works by just listening for requests to make channels (i think i called it bands at the time because i like the radio metaphor) and then creating lrc channels as needed. this is basically the model for xcvr.org today except that those requests happen through atproto xrpc where applicable.
as you can see with it if you check it out, (and of course this is there also in og lrc) there's no chat history. that's just how lrc works. i'm not totally sure when certain changes were made, but if you start a message in one tab and then open the same band in another tab, and continue with the message, it's not really a gimmick that the user's name is blank and the message is missing parts, (ok i checked it and this actually isn't present in xcvr.chat, but it was that way in LunaRC, the TUI) the server doesn't know that anymore. so kinda the main idea with adding atproto is to solve this issue of chat history, and identity.
xcvr.org
ok that's not really the main idea, the real main idea is to recapture the energy that i felt 3 years ago when i saw that god damn text messaging didn't have to be so lifeless, and to try and use it to breathe life into the weird stratified grapevine of twitter.gov, ultimately giving people the technology to distinguish man from machine, and-emdash-but that's too soon. there is still so much work to be done, and only so little has been done.
but what has?
initial lexicons - complete (but not posted, like the actual lexicon definitions idk if they're good enough and some of the posting about them needing to be permanently future compatible, idk squigged me the wrong way a little bit. but we'll get to that when we do)
records
org.xcvr.actor.profile WOW WHO CAN GUESS WHAT THIS IS
org.xcvr.feed.channel this is a bit more interesting, if only because you declare a host for the channel, which if it's a valid host, will then accept lrc connections for a server there
org.xcvr.lrc.message is of course a declaration that you posted a message
org.xcvr.lrc.signet is a declaration from the host of the server that a message was posted, which allows for bidirectional verification of messages
methods
org.xcvr.feed.resolveChannel does the actual channel resolution mechanism. for a host to be valid, it must resolve a record key + at-identifier into a path for the lrc websocket server
org.xcvr.lrc.getMessages (and others like this, you get the rest blah blah)
lexicons don't mean much without auth-emdash-or do they?
since i've been a bit inspired by the site formerly known as bw, and because my extreme anxiety and general lack of friends has lead to me not sharing my work with anyone that has required moderation so far, and because it makes testing things whenever i break oauth far easier, i allow you to post without auth, to the xcvr.org repository. besides, it's actually moderately complex to allow people to see the contents of a thread without letting them post in it if they don't have auth. ok saying that out loud makes me sound very stupid-emdash-and i am!
well, in any case, i've also added oauth, twice. all the backend has been in go this whole time, so it was kinda a silly ordeal doing it all with hailey's library for oauth, and then i added it again a lil bit better and cleaner with the indigo oauth implementation. move slow and learn things.... it's a way to live life. normally the long way is actually shorter.
um so we've (we've = me've) also done some frontend work, and of course the main event is that there's a database now. and i listen to jetstream. and there's a second websocket. and there might be a third any day now, because when all you have is hammers...
still mostly sitting here blooping things into my computer. sometimes it beeps happy frequencies at me, and sometimes i have to ctrl b d ssh xcvr tmux a ctrl c vim log.txt } and stare at my horrible mess of logging that's only my fault and only understandable by me for half a day.
i program computer and it programs me.
onwards
on the horizon, i really feel like images are something that it sorely lacks. once i've mastered blobs, i feel like i will finally feel ok saying that i've made a half decent messaging application.
ok i also will need notifications for that.
this probably seems like a pretty strange entry point into things, but if you click on xcvr.org i guess this will seem more harmonious since i guess i'm too stupid perhaps to know how to present myself in a different manner. oh well, in another life!
i guess if you're to empathize with me an ounce, it's a pretty strange situation if you're in my position, because i'm more or less trying to prefigure an internet community in order to prefigure more of a niche political social project, but the only way i know how to do this is through the practices and discourses of founding a social media startup, which is kinda what i really am not totally interested in.
in any case, this is my development blog for now. my personal blog which was more of my development blog, is on moth11.net, and i'll probably continue updating both of these in parallel for however long seems appropriate. i