tom.sherman.is
Software Engineer in Norwich, UK. he/him
Working on @frontpage.fyi
https://tom-sherman.com
2,234 posts
3,808 followers
296 following
Regular Contributor
Active Commenter
comment in response to
post
pls sir can we have some cids
comment in response to
post
Hmmm, can't the react compiler pick up the pieces on runtime perf here?
comment in response to
post
Nice, I can rack up a $100k AWS bill for you from a single bash script now
comment in response to
post
Shipped in v0.2.0!
comment in response to
post
How does lexicons.json sound?
comment in response to
post
atproto.com/specs/lexico... formalises who "owns" a lexicon
github.com/bluesky-soci... gives some additional context, especially the paragraph starting "Who will need to resolve NSIDs to Lexicons, and when?"
comment in response to
post
Is the convention of having the lexicons saved in a folder as a sibling to the manifest an issue for you?
FWIW, I need to change the name of the manifest to something more descriptive
comment in response to
post
Copilot o3-mini wrote 95% of the code for this command, thanks @ngerakines.me 😂
comment in response to
post
Same
comment in response to
post
As an extra bonus you can also navigate to lexicons using a lex URI eg. lex:bsky.app.feed.post
comment in response to
post
I always assumed the value in take-home tasks wasn't in proving you could complete it, but that you could discuss your choices and trade offs afterwards
comment in response to
post
Then what am I paying him for 🤔
comment in response to
post
I dunno, maybe a little. The vibes are off IMO but happy to be proven wrong if they ship something of value
comment in response to
post
This is super important PR that removes 5 bytes from the bundle. Really great to see the Bluesky team focussing on performance
comment in response to
post
Lmao. Lol, even
comment in response to
post
I need context
comment in response to
post
@tom.sherman.is bruh
comment in response to
post
Handle invalid 😞
comment in response to
post
You are so right, entirely forgot I bought this domain. I would like to thank the Republic of Iceland for this opportunity
comment in response to
post
Cool idea tho, especially if it's backed off of the schemas being published on the firehose???
If so that gives a nice way to logically group threads too, all new things under the same authority could go into a single thread
comment in response to
post
Interoperability nightmare haha. Would be sick with something like traits tho
comment in response to
post
Love this Boris! And congrats!
comment in response to
post
✨ Encapsulation ✨
comment in response to
post
Yeah bridgy doesn't actually serve a profile page, it just redirects to the bluesky profile URL
The only way to see it is to go into a mastodon client and use the search, then pray it doesn't redirect you away 😆
comment in response to
post
Your PDS only cares about your DID when creating records, it's not gonna stop you from doing that if you don't have a valid handle
comment in response to
post
There are tools to help you explore the storage layer of atproto (PDS) like atproto-browser.vercel.app/at/richfish.net
comment in response to
post
real
comment in response to
post
Easy fix in the end github.com/likeandscribe/fr…
comment in response to
post
You have to wonder how much of this is driven by ByteDance not wanting to be reliant on a competitor for this tech (Meta). Motivations aside, competition to React Native is good to see!
comment in response to
post
Yeah I was just trying to think through how you'd do it, I dunno if there's a better way than having a big list of all of the AppView routes 😅 altho I suppose maybe you could route add the AppView did service when you see a app.bsky prefixed NSID in the http client
comment in response to
post
cc @retr0.id
comment in response to
post
Ah, nice. Didn't realise the did:web already existed
I might raise a PR to the bsky client to add this header in, then - being explicit would be nice and allow for third party implementations to skip implementing this fall through and continue to be able to use bsky.app
comment in response to
post
3. Eventually remove support for this fall through routing within the PDS (when all clients have updated to be passing the appropriate header)
@bnewbold.net thoughts?
comment in response to
post
Rolling this out probably requires careful sequencing
1. Publish a did doc for did:web:api.bsky.app with a bsky_appview service definition
2. Update the bsky app to add the atproto-proxy header to relevant requests (probably requires changes to lex-cli and @atproto/ packages)
comment in response to
post
- New PDS implementations would be slightly simpler - they wouldn't need to know about this fall-through behaviour (technically it's optional, but users on your PDS won't be able to use bsky without it sooooo)
comment in response to
post
Other than being cleaner, it has some other benefits:
- Better error messaging when providing the wrong DID in the proxy
- The appview service would be discoverable on the protocol (right now did:web:app.bsky.app doesn't even exist), making it easier for a client to swap between appviews
comment in response to
post
"Oop" indeed