for the past few days i've been working on Talk To You! Transceiver (tty!xcvr) a terminal user interface for xcvr
talk to you! transceiver #atproto tangled.org/@moth11.net/...
i've been having so much fun with it!
as i was saying in my first blog post here, xcvr.org originated as live relay chat (lrc), and my first client for it was LunaRC, in february and march. at the time i really didn't know much about much, and i ended up trying to create a complex tui from scratch, alongside a binary protocol for a rapidly evolving thing. it was a mess!
that project rotted into xcvr, the hybrid lrc/atproto chat app that we all know and love. but in the back of my mind, the feminine urge to have a cutie paTUI remained. i think there's just something that feels more human-scale about programming a terminal application vs a web application; using just one language with minimal libraries and most of all being able to just make the mvp right now. in the past few weeks i've randomly experimented a bit with electron, wails, and even secret third framework, and it's just so painful how hard it is to go from 0 to words on screen to http request & more
i became aware of bubbletea, an elm-based tui framework for go, when i created a lil stream.place chat program, and it was actually exactly how i was trying to make LunaRC back in the day, except it actually works, haha
but it's not enough to have a latent desire to make something and the understanding of how to make it. you still need an impulse that gets you out of the library and into the street. for me, that was migrating the xcvr.org repo from a bsky.network pds to my own pds, monday and tuesday of this week. i'd been planning on doing this forever, but i felt like the recent atmosphere in the ATmosphere got me to feel like it's quite a good idea to have a bit of an understanding about how the PDS migration process works in practice, and I felt like in the scheme of things it's not the worst if that account went kaput, and theoretically if my PDS was on the same server as xcvr.org appview app server i quite like "lexview" as a new name for appview since it helps newer devs and atproto-curious folx become aware that there are n-lexicons out there (i might be biased...)
anyway, if my PDS is on the same server as the lexview, then record propagation is faster and it's ultimately less likely that a client fails to recieve the signet URI in time for their message to be created. the joys of codifying a microservice architecture...
anyway, PDS migration went very smooth, but that's actually not the instigating incident which led to my obsession over the past 3 days which led to Talk To You! Transceiver
the instigating incident was after migrating my PDS, when i made some test posts from the command line using goat. there's just something about a good cli tool, where even when there's literally 0 juice at all, it can make the most mundane experience feel so unfamiliar and HACKERS-like
so thursday and friday were basically 12+ hour days beepn and borpn
Talk To You! Transceiver is certainly still a WIP, but i had a few relatively long chats on it morning which went well. honestly it does a somewhat better job than xcvr.org, there's one annoying bug in that site . as i say in the video announcing it friday night, it does fully support the creation of org.xcvr.lrc.message records right now, just like the xcvr.org client, ideally it's going to be a more or less 1-1 port of xcvr.org (i don't know if you can do oauth in command line, so i think it's only going to support app-passwords, like goat, for now, which i think is ideal, though of course app-passwords are "outdated" and "bad practice" or whatever)
I WAS INTERRUPTED IN THE WRITING OF THIS POST AND I FORGOT WHERE I WAS GOING IF ANYWHERE AT ALL. FORGIVE ME. TAKE CARE. BRING SOMETHING INCOMPREHENSIBLE INTO THE WORLD!
rachel