""Autonomously, an Antigravity Agent writes code for a new frontend feature, uses the terminal to launch localhost, and actuates the browser to test that the new feature works."
very interesting times; i'm glad to see browser automation becoming more mainstream as part of the ai-assisted dev loop for testing. (disclosure: started the selenium project, now working on something similar for a vibe coding context)
Most people are missing the point here. Testing the GUI/feature more reliable is something that Gemini 3 could unlock (looking at the ScreenSpot-Pro benchmark and its general improvement on visual understanding). At least for the (hobby-)projects I attempted this was really a bottleneck having to always test the GUI after each change as its quite often breaking something.
same. i don't like async. i don't like having to prepend "await" to every line of code. instead, lately (in js), i've been playing more with worker threads, message passing, and the "atomics" api. i get the benefits of concurrency without the extra async/await-everywhere baggage.
I don't use it myself so to speak, except to fill in some things sometimes like passwords. The LLM is the user. It just uses the primitives it has (these are my paraphrases): scroll_to, expand_viewport, screenshot, select_dom_element, fill_input. This way I can tell it to implement a feature and verify it and it does so in a Google Chrome testing profile. Without the grounding, I've noticed that LLMs often produce "code that should work" but then something else is missing. This way, by the time I see it, the feature works.
I then have to go in and advise it on factoring and things like that, but the functionality itself is present and working.
just a theory, but as atproto matures, there are now other example projects using the protocol for other things besides "distributed twitter clone". for example, tangled was talked about yesterday. [1]
and that probably came up because more people are wondering about the future of github as it becomes more integrated into microsoft. as things become more centralized, interest in decentralization goes up.
To give you an example, https://slices-teal-relay.bigmoves.deno.net/ is a demo of Slices showing the latest teal.fm records (like Last.fm scrobbles). The thing is, teal.fm is not even launched as an app. It's just its developers already listen to music through it, the records get created in their repos, and so any other developer can aggregate their records and display them.
It's a web of realtime hyperlinked JSON created by different apps. That's exciting.
I wonder if one could perhaps create an RSS reader app by piggybacking on ATProto purely for broadcasting change events, with the feed themselves still located at their traditional address? Basically reviving Google Reader on ATProto infra.
thank you for sharing these links, if it isn't too much to ask, could you or someone reading this compile a list of useful / interesting ATproto endpoints for HN?
i'm very curious about tangled. i'm building a new thing (tl;dr: an e2e testing and monitoring service) and hope to add more distributed/decentralized functionality into its core. i had been leaning heavily towards using nostr at the core, but it's nice to see atproto-based examples i can learn from, too.
that is the best and worst aspect or nostr. it is a very interesting, semi-chaotic box of new toys to play with. reminds me of the early web. (the second best/worst aspect of nostr is key rotation.)
from an an average developer perspective, nostr is interesting because it's "just" a digitally signed json data structure sent over a websocket. reading the spec [1] for creating a simple nostr client (aka "nip-1"), my average developer brains thinks: i could do that.
i don't get that same feeling when reading atproto or activitypub docs. ultimately, there's a reason why all these protocols get complicated at scale, but in the simple case, nostr is very easy to make a client for and start playing with.
nostr feels like a good example case for gall's law: "a complex system that works is invariably found to have evolved from a simple system that worked."
For me, as a veteran of social networks since Fidonet, the question that actually matters is the social construction: who's using it, for what purposes and topics, and - crucially - how is the work of moderation (including spam and abuse prevention) handled.
Technology doesn't make or break these things, the users do.
What questions do you have about AT? I agree its docs are mostly “bad” and hard to understand. I find the actual tech approachable so happy to answer more concrete questions.
Tools like http://pdsls.dev in particular can be helpful to see how things fit together.
i think it really is as simple as boiling it down into a doc that looks like nip-1 and saying, "this is the absolute minimum amount you need to understand and implement to start sending messages on an AT-based network." -- not from a user perspective, but from an average developer perspective.
i know eventually i'd need to implement a ton more than the absolute bare minimum, but my gut-feeling "average developer brain" says nostr's absolute minimum feels smaller that AT's absolute minimum. i guess i'm looking for an AT doc for devs that shows the absolute minimum for creating a client that is equally approachable as NIP-1.
thanks. also, fwiw, i'm also a very a happy AT user (@hugs.bsky.social) besides also being a happy nostr user.
i appreciate bsky's focus on user ux and community building and look forward to seeing more sharing of ideas between nostr and AT.
edit to add: to nerd-snipe my brain into wanting to make stuff with AT (or any future protocol) is to focus on a quick-start or tutorial showing the absolute minimal client to send one message.
once i can do that... i'm ready to learn all the rest of the vocabulary and server-side stuff, but not until i can send one simple message from a barely functional minimal client.
i like seeing a bit of the raw, low-level protocol first. a few curl examples are perfect for understanding what’s really happening under the hood. once i get that, i'm happy to use a library to handle all the edge cases.
but starting with a library tutorial makes me wonder how many stacks of turtles are being hidden. if i can see the turtles upfront, i'll appreciate what the library does for me -- and i'll have a better sense of how to debug when things break.
I kind of feel like you’re taking one of the specs from nostr - the first one written - and calling that the whole protocol. Then you’re comparing all of the atproto specs to that one spec.
The substantive difference is that we didn’t do a mix & match spec process because we knew the ambiguity of spec support causes problems, just as it did with XMPP. Protocol specs only get implemented a few times. The meaningful developer choices are in schemas and business logic.
But that's essentially the whole protocol. You can implement a client or a server reading only NIP-01 and it will be able to interoperate with the rest of Nostr.
Reading and implementing NIP-01 can be done in an afternoon (or a weekend if you're taking your time), and it gets you relays that can accommodate multiple clients and applications. From the client perspective, only implementing NIP-01 gets you a simple Twitter clone with an identity that belongs to you.
the spirit of my comment was more psychological than technical. nip-1 successfully nerd-sniped my brain into thinking it was easy to get started with a simple, barely functional client. (even though, you're right, at scale, everything gets complicated and is not easy.)
perhaps this a roundabout way of hoping there is already a developer-focused quick start or tutorial for making a barely functional AT client. it either already exists, but i didn't look hard enough for it, or it might only be one chatgpt or claude prompt away.
Both of these systems are rebellions against the structure of secure-scuttlebot, but took different paths as they rebelled.
Beyond using different cryptography, the biggest difference between the "ATProto System" and the "Nostr System" is that Jay Graber wanted to account for deletes and the re-organization of the message structure of an entire feed.
In early ATProto, aka smor-serve, https://github.com/arcalinea/smor-serve Jay didn't like that we couldn't delete a message on SSB so she centralized all of the operations into a "repo" where we can modify our social feed as much as we want, including even backdating posts. We can see how that evolved into how ATProto currently works today by browsing a repo with pdsls.
For Nostr NIP-01 to work, we generate a keypair, sign a message and blast it at a relay. There's no structure at all to how the messages are organized. Messages are out there once they are sent to the relays. This lack of structure leads to all kinds of issues about how one develops a strategy for syncing an entire history of a feed.
Both of these systems have developed into far larger complex systems that are impossible to hold in anyone's mind at this point, but the key difference is being able to delete a message. Most of the complexity in the "ATProto System" results from accounting for a message that one sends and then wants to unsend later. This is why everyone complains that Bluesky is centralized on the AppView/Index layer. But it's also centralized at the PDS layer.
Correct me if I'm wrong but I think another important aspect of AT is Lexicons, i.e. there's an officially suggested way to do schemas, and application authors are encouraged to create and distribute schemas for their apps. Data is grouped in the repo by its schema too.
The more nerds that get sniped by a simple-seeming protocol, the more likely it is to catch on. Hitting a 100 page spec doc full of XML and links to other specs is a big de-motivator to start hacking on the protocol.
NGL that's kind of been the appeal of atproto. Once you get into the weeds you start learning about all the many many many moving parts but at its face 99% of it is:
Hey here's some schema files we call lexicons. Every single interaction with the network is a JSON RPC call to the same domain (whatever your PDS is) with the lexicon's path appended to it.
The fact that it's trivial to hack on atproto via the devtools console or a curl prompt makes things so much more fun to play with.
Yeah, although I would argue that there are far fewer moving pieces in Nostr than there are in ATProto and that's part of why it's so simple - it's just clients and relays. That's it!
Edit: another thing I thought about just now is that you don't really have to worry about implementing most NIPs - many are not relevant if you're just building an application. All the Bitcoin Lightning Network stuff, for example, or private messaging, Blossom, etc.
yes, "there are too many NIPs!" feels like a red herring. at the moment, as a developer, i feel comfortable picking and choosing which NIPs i might want to use for whatever i'm building. but i can also understand why that might be a little confusing/frustrating to others. might be a education/communication issue more than anything else.
both projects are "controlled chaos", where nostr is a little heavier on the "chaos", atproto is a little heavier on the "control".
"By 1965, it moved to Paramount Ranch in the Santa Monica Mountains"
Fun personal fact: Paramount Ranch was also the site of my high school's home cross country course (Westlake High School). During my high school days, the ranch's center was set up as a western town for filming Dr. Quinn, Medicine Woman. As a kid, you just accept all of that as normal, everyday things. "Doesn't everyone have Renaissance fairs and TV and movie sets in their town?" It took going to college thousands of miles away to realize and appreciate how delightfully weird Southern California can be.
i've been working on an idea for a while to use those idle old phones for... distributed web and app testing. plug it in at night... wake up having made a few bucks.
problem is getting anyone to really care, though. cloud hosting is cheap.
reply