I’m a browser engineer working on Google Chrome and I work on Web Platform APIs (WebOTP, FedCM, Digital Credentials, Email Verification Protocol and TC39 in Chrome … schema.org in my past life in Google Search … and OpenSocial / Salmon / ActivityStreams in my past past life on Orkut.com … yeah, I like open ecosystems :))!
I’m a big fan of atproto and have been using it for a while (although I failed at running my own PDS :(), and I think atproto (and other comparable things, like activity pub and so on) is a great step to make the web better!
I can not make any promises that anything will actually change (it is not like I have a “sudo” here), but I figured it would be useful to at least ask the question: are there ways that you think the browser is holding this community back? Any ideas that you think are lacking in the browser?
Ben Vandersloot was implementing FedCM at Mozilla but got pulled into other things, I think. In case you can help get it reprioritized, it would be great!
A couple things come to mind, there’s probably a bunch more.
One thing that would help is BLAKE-3 support. In general, anything that helps content addressing work better (given that AT builds on DASL) helps AT. BLAKE-3 didn’t become the default hash for DASL CIDs in large part because of the lack of browser support. But projects that deal with large chunks of data, be it Stream.place, science stuff, doing verifiable range requests so as to query a remote DuckDB of the whole Atmosphere would benefit from that.
There’s also ongoing work on small contained web apps that could be safely embedded into social contexts (also being worked on as part of DASL) shipped over AT. These could benefit from the ability to create an opaque origin (or some form of partitioned suborigin) and attach a service worker to it or even just the ability to process fetch events for it. (Right now you can have the former with sandboxing but the moment you do SWs don’t work.)
@sgo.to One idea I’d love your thoughts on is making it obvious to non‑technical users when a site can store data on their PDS and “speaks atproto,” so they see the concrete benefit first. A possible way to do this could be a dedicated .atproto TLD that clearly signals this capability to users. I’m not fully sure how feasible this is on the standards side, but I’ve seen things like .google in the wild, so I’m curious how much of this could be done via browser‑level support. Alternatively, it could be an icon near the domain name (I find the SkyLink chrome extension to be quite clever in detecting that a website has atproto presence https://chromewebstore.google.com/detail/skylink-bluesky-did-detec/aflpfginfpjhanhkmdpohpggpolfopmb
users login once in the browser, then websites request permissions to publish AT records on their behalf
this way atproto apps don’t even need to implement oauth, they just use the API and the user agent takes care of the rest
navigator.at.identity.did
navigator.at.publish()
This could probably be started with a web extension that provides the material to pages. Ideally with a library that pages can ponyfill on, since adoption will at first be so so.
Interestingly, while fedcm is an effort that will (at least partially) solve this autofill issue, password managers can and do act as a polyfill for that kind of experience.
While standards bodies are slower to move, it could be interesting to get buy-in from password manager extension providers to support these kinds of use cases at the code level so web developers can begin hooking into that kind of infra. Test in the market, work out the UX and security kinks, bring that info and adoption numbers back to the browser devs and standards bodies. Different form of advocacy with faster turn around on the market if successful.
Also, we could just do this ourselves in the ecosystem with an atproto login extension.
@sgo.to Has anyone built a fedcm polyfill extension? If there is one already we could play with it here, learn together, and share the community’s conclusions back to people trying to make it happen within the browsers while also semi-solving this pain point for those who are willing to install browser extensions.
If not, maybe this is a great opportunity to create a polyfill with the atproto ecosystem at the center. If something about it doesn’t work, the atproto ecosystem can propose changes to the current spec(s) on the table.
Small update on FedCM: Bluesky Social PBC have given me a grant to work on it for one year within the FedID Working Group (I’m an invited expert there). Full announcement here: Working to Decentralize FedCM - AT Protocol
