myXCVR app

HI THERE!!!

i haven't been posting my development blogs regularly lately, but i have been working! not on polishing images, as i said i would, but instead on an app! at://xcvr is coming to ios sooner than you might think!

ok that's enough exclamation points, but i am quite excited because ultimately, a goal of this whole lrc/xcvr adventure has been to get myself off of discord, and the main place that i use it is on my phone, and while xcvr.org works on mobile, it's quite hard to make a good mobile website, especially since i have a personal aesthetical disinterest in tailwind & co

this is my first mobile app, so i think the past 4 weeks have been a bit of a crash course in swift, swiftui, native oauth, and then putting stuff together. also i think i relapsed on Dota 2 which set me back 2 weeks, probably T_T

anyway, it really is starting to come together, and for the past week or so, i've been having daily chats on at://xcvr at 5pm eastern BE THERE OR BE SQUARE, everyone is welcome to join, and the past 2 days myXCVR has been complete enough that i've been able to have the chat on myXCVR, the messages getting posted to user repo and everything

also, because i love graphic design and typography a lot, i've had a rule to leave all of the styling in most of my projects default, minimal css etc... web1.0, but i have started to break some of those rules with myxcvr lately, really i've enjoyed liquid glass

**************

now here are some recent thoughts for the technically inclined, esp. apropos mobile oauth:

i'm not sure if i'm like doing things wrong or anything, but for my app server rvcx, this holds all of the oauth client info in a database, the keys to which are in ur browser's cookies, encrypted so you can't access someone elses oauth client, right. and in order to for instance make a channel, you use a non xrpc api endpoint that checks if you have an oauth client, and then the backend will communicate with your pds to create the channel, then it sets up the channel (if it's hosted on the app server), and then it responds 200 ok. this all feels good to me

(and this is kinda all in reference to pauls post: https://pfrazee.leaflet.pub/3m5hwua4sh22v )

but for mobile oauth, since the redirect uri is the universal link or whatever, the oauth client is on device, and not on the app server, right? so i think even if we didn't care about supporting option 1, the more old school atproto way of doing things, isn't that basically how mobile apps have to end up? or am i missing something here

(i especially feel like i'm missing something because i think that mobile apps oauth clients seem to have a 15 day session maximum duration)

in any case, if we still have in mind the channel record in xcvr, you can't connect to the lrc server and xcvr event stream until the channel record has propagated through the atmosphere and made it to the host server, of course. when i create a channel, the ux flow we want is to take you to the created channel right away, so if we go with option 1, this would of course lead to a race, and likely the request to connect to websockets would fail. what i do right now is i just poll the host server's getChannel() xrpc endpoint, because once that succeeds, the host server should be listening on websockets, but the pattern that i think is better in general for atproto is that our app server should try and resolve a record referenced by uri directly from the pds, if we don't have it in our cache, instead of returning 404 right away. this doesn't fix all of the issues that we care about, maybe i want to see my tweet in the timeline right away, and in this case we're not giving the app server a uri, but oh well.

i also liked the pattern someone mentioned somewhere in the replies which is to just tell the appserver about the uri, however this of course isn't as ideal if the lexicon has multiple app servers. honestly though, while i hear the potential complaints that some bad app servers might take a long time to put their record out there into the void, it looks to me when i've been working with xcvr that record propogation is really really quick, so i think that most real-time chat apps for instance don't really care in this case. i definitely think that for hyper-real-time communication, it's not super feasible to do on atproto at the moment without some sort of model like i have in being possible in lrc, but i think if someone makes good ol ATrelay chat, it should be perfectly fast if the clients go directly to pds, as long as you're connected to jet stream or have an event stream that's connected to jet stream / firehose

BTW! xcvr is connected to jet stream, not even firehose, so i think even with that extra overhead it's still normally under 2 seconds for the real-time chat component from the direct to pds records to propagate, which i think should be perfectly acceptable for real-time chat

**********

tbh, i don't really understand app store, and they have a whole bunch of rules and all that crap, so i can't give a perfect~ timeline for when myXCVR 1.0 will be released, but i think i'd like to spend a bit of time trying to get images to work on it, and then i think i need to add some reporting stuff to the backend. those are kinda the main features i wanna add this week. otherwise, i believe i currently support all of lrc, xcvr/profile, channel, message, and signet, and the ux isn't totally terrible

maybe like week of thanksgiving it will be mostly app store ready?

we'll see!

-rachel