char.lt
charlotte or cinnamon. 24 ^-^
technician & artist
en/fr/한/es OK, 🔎 char.lt/bio
2,589 posts
4,552 followers
367 following
Regular Contributor
Active Commenter
comment in response to
post
explainxkcd has transcripts
comment in response to
post
i think if you're using it for wallet addresses it might be worth doing bip32 properly so you can have multiple from one mnemonic; mine's just for plc rotation keys really
comment in response to
post
anyway i think on android at least u might be able to do something silly with app: uris
comment in response to
post
i really wanted a logout route like soundcloud :(
comment in response to
post
i think it's like three months old
comment in response to
post
if u throw the string into a JSFuck compiler u get something around 360 characters which does not fit in a bsky post
comment in response to
post
that's ($=>(_=>(_+`/`+_+(!_+[])[$]))((!``/[]+[])[$]+(!``+[])[$-$]))(!``+!``+!``)
comment in response to
post
they're RLHFing oomf in the replies
comment in response to
post
please dont disparage the wonderful regiolect of oomf jersey
comment in response to
post
yeah i use squoosh when i want to control the quality parameter ^-^
comment in response to
post
i wrote a minifier once its soooo useful
comment in response to
post
that domain doesnt point anywhere ^w^
comment in response to
post
idk theres nothing stopping a pds from using a key per user
comment in response to
post
yeah but its a shame theyre mostly per-pds by default instead of per-user
comment in response to
post
the core is very simple anyhow: auth with both something only the app backend knows AND something only the clientside application knows. it de-risks the black box
comment in response to
post
i mean we're talking about it today because of the oauth thing right
comment in response to
post
on oauth in particular i think it would solve some concerns if the client could pepper the pds' tokens with additional cryptographic state on the first request
this way u need access to the nonces AND the server's tokens, so u can't make spurious requests without going through the user's own device
comment in response to
post
and im not really pressed at all when we're talking about backend-for-frontend as in some backend service that augments the abilities of an otherwise clientside-only web application (e.g. cardyb for social-app). but its a term that's overloaded to fuck
comment in response to
post
i'm a lot less pressed about backend-for-frontend as in the promotion of confidential oauth clients than about bff as in the model where you hit some centralized API that holds PDS keys & optimistically processes your request while voluntarily writing it to the PDS as an afterthought
comment in response to
post
provided confidential oauth against a pds works like how it does (ime) against e.g. a mastodon instance
comment in response to
post
at the very least im pretty sure u just have to hit up the guy for a jwt and not actually proxy request data through
comment in response to
post
i make my pdses treat aglais and pdsls as first party apps so i dont really get signed out of those even on devices i touch rarely which is nice
comment in response to
post
i definitely trust my own endpoint for cryptographic custody more than some loadbearing service lol
i like that all this decisionmaking at least happens on the PDS though; we can just roll our own thing . sucks for median user though
comment in response to
post
the idea of a bluesky client having to proxy requests to a server who could be logging god knows what just so i don't get logged out at the end of the week disgusts me
comment in response to
post
hehe <3
comment in response to
post
big fan
comment in response to
post
low key i kinda put cerulea down when the mainnet relay stopped having so much downtime. also the sync 1.1 relays kind of accomplish the same goal as the cerulea implementation so the bet is probably to use rsky-relay with a little filtering on the hosts that get subscribed to
comment in response to
post
caveat emptor cerulea has not been touched in a while and isn't Sync 1.1 compatible (and I'm pretty sure the way I serde things it'll just eat the extra fields on your commit ops)
comment in response to
post
sick omg
comment in response to
post
oh sick
comment in response to
post
if you know you're falling back to the canonical directory though you can definitely just prune spurious ops at the ingest phase
comment in response to
post
be warned it uses a few hundred gb of disk atp because of the plc spammers
comment in response to
post
since plc.directory doesnt have an event stream subscription or anything the ingester has to poll slowly so if the local lookup fails you need to fall back to looking up the did at the central store but it's nice to have a local replica that all ur services can share and super greatly reduce traffic
comment in response to
post
fwiw if all the relay needs to do is fetch did docs (and not hit audit endpoints or anything), zplc/serve-plc.ts will fetch and present did docs out of its op log (you just have to run the ingest script without setting ZPLC_NO_RAW_LOG), which is what I use to avoid the plc ratelimit in my AppViews
comment in response to
post
true!
comment in response to
post
you're telling me a surrogate pair coded this unit
comment in response to
post
very funny to use characters outside the BMP for this i know ur gonna fuck up some java users
comment in response to
post
a male sub is called a "submissif"