๐ bluesky team
oh yeah, look at that! i didn't realize that wasn't exposed on web, feels a little odd to me. the next best thing is probably to reconnect after n seconds of not receiving any data. it's nice to see more clients that handle lexicon subscriptions!
just in case you haven't already bumped into it / dealt with itโregularly sending a websocket "ping" and looking for a "pong" back is pretty critical to ensure your connection isn't only half-open (e.g. if the other side or an intermediary has an oopsie).
i had the pleasure of standing up the initial prod servers so i had the opportunity, but gladly left it to @pfrazee.com iirc
it had to do with decoding multiple cbor data items. support was added to the cborg package used within @ipld/dag-cbor so we should be able to replace cbor-x now.
it's gonna be a loud show tonight
Don't mess around. Comment below and like this video.Listen to Keep Slipping Away on Spotify here:https://open.spotify.com/album/50PjONTHKBY16l7gQ390B0Listen...
youtu.begood q! practically speaking right now, it is globally unique. but you might notice the API doesn't rely on that. for example, `deleteMessageForSelf` takes both a conversation id and message id. could imagine taking advantage of this in the future to scale things out.
there's a lot tbd, but we'll certainly be looking at use cases beyond dms. can you share any details on your use case?
we're investigating the addition of transparency logs to plcโ there are a few notes on this in the 2024 protocol roadmap: docs.bsky.app/blog/2024-pr...
Discuss this post in our Github Discussion forums here
docs.bsky.appyup, that's right! it's a significant effort to relate e2ee functionality into the protocol, and we want to nail it. the service itself is centralized but uses the same decentralized identity system as the rest of atproto. if you're familiar with atproto concepts, it's essentially DID-to-DID dms.
floored that i was lucky enough to catch codeine in 2024, 30 years after they split up. and they cruuuuuuushed.
shared by the Billy Ruane live archive preservation, videotaped by Jody Urbati-Moore
youtu.bethere are a fair number of files, but we actually make an effort not to make the directories too big on the pds ๐
i feel that! but as i think you may be getting at, slicing code points vs. utf8 isn't the source of the problem there.
walking away from slices, it would be a touch sad to give up { "text": "show the world my poast" }, but there are some pretty nice upsides of course.
it's funny, i like how it works! utf8 byte slices are commonplace and can be worked with concretely. code points are virtual, subject to the quirks of unicode and your language. e.g. js is still special here thanks to utf16: you can find surrogate code points in strings, not just unicode scalars.
exactly! it's for the UI "Reply to {user}" appearing on reply parents in feeds/timeline.
yeah good call out! we're considering the bot use case ๐ my hope ๐ค is that we can actually make them easier to operate than they are today.
you make the same request to createSession again, but the second time include code in the `emailAuthFactor` param. some details here: github.com/bluesky-soci...
Hey all! Quick update on some changes rolling out to the session APIs. We are currently putting the final touches on OAuth, which is going to fully replace the session management in atproto. Howeve...
github.com@mnot.net has countless great http writeups, one of which touches on browser behaviors around this exact thing!
A long, long time ago, I wrote some tests using XmlHttpRequest
to figure out how well browser caches behaved, and wrote up the
results.
200s are "heuristically cacheable" but many error status codes aren't. so to avoid caching shenanigans may at least want to toss a no-store on those kinds of responses.
thanks for following up! i poked around at this and wasn't getting very far, as it looks like the mail is being accepted properly by aws email servers. in any case, glad you got this working and i'll continue to be on the lookout for similar issues! ๐
@monicarose.ca @meson.ninja two questions to help us poke at this! how are you kicking off the email verification flow (e.g. which dialog appears in the app)? and are you replying from the same account whose email you're trying to verify?
give this another shot and let us know if you have any luck! pretty sure we were able to fix this hiccup ๐ค
Efren โBataโ Reyes trickshot.See also:Efren โBataโ Reyes supershot from his Farewell Tourhttps://youtu.be/hRn4vX0d6xsGreatest 9-ball Break ever!https://youtu...
youtu.be@n3pm.bsky.social try giving this another whirl! if it's back to normal we thank @jaz.bsky.social for the assist โจ
yupyup! it shouldn't affect refresh tokens from another session. the idea is essentially that you can't take one session and branch it into two sessions (i.e. by using the same refresh token twice). this can get a little tricky if you have two browser tabs that are sharing a single session/token.
the refresh tokens are single-use, and when you use it you receive a new, fresh one. i expect what's happening here is that the same refresh token is being used multiple times. when you use the refresh token, just double check that you're updating both your active access and refresh tokens.
i see the error code/name is ExpiredToken. what is the corresponding error message that comes with it?