In some ways, atproto, bluesky, @semble.so, @sill.social, @standard.site and so on are building new indexes for the web. I really hope atproto succeeds and goes fully mainstream. Think of the amazing search engines that can be built on such rich index data. Maybe web3 can actually happen.

Had fun adding support for @standard.site to my blog. The richer preview card on #bsky looks neat. Another benefit is, since all the entries now live in the #ATmosphere, all kinds of #ATProto apps can index and display them. See pckt example: pckt.blog/read?search=rednafi rednafi.com/misc/standard-site/

@tynanpurdy.com asked for this feature and I like it: every atproto app should support AT-URIs as top level routes, @pds.ls-style. Makes it super easy to integrate. So this would be an argument for e.g.: `https://bsky.app/at://did:plc:rbvrr34edl5ddpuwcubjiost/app.bsky.feed.post/3micfxauzu22c`

btw, these new domain endings should be of much greater interest to the @bsky.app (atproto) community than your average internet jane/joe because of the incoming flood of expressive @handle.tld options

Bluesky is a dominating presence in microblogging on ATproto, I just posted from both Mu and Blacksky and they’re both still using app.bsky.feed.post records. But what if there was a community driven standard for microblogging the same way we have one for long-form posting with @standard.site?

Tried to explain a bit of the use case of @varsityapex.com and why it made sense to integrate ATproto features. A full fledged site would make even more use, for the demo just opted to make records of non-score items. Tour: varsityapex.com/tour Was fun to explore the problem space a bit

for other atproto ecosystem folks: most things are working smoothly, but you may be seeing slow (high p99) handle resolution (via HTTPS well-known) for *.bsky.social handles (even projects which don't rely on bsky services often need to resolve handles as part of interop)

the general bsky userbase being a lil dismissive of the standard.site integration is a reminder that this whole atproto atmosphere ecosystem is a long game. not everyone will be on board, and that's ok! we'll be ready to welcome people into a decentralized social future as big social fades away :)

atproto'd my website a bit further (beyond the @standard.site integration): 1) added a "Right now" box on the homage that pulls in all kinds of atproto activity like @bsky.app posts, @popfeed.social film ratings, @bookhive.buzz reads, @tangled.org repo's etc.

Added support for Standard.site to cross-posted Bluesky posts. This is a new convention for long-form blogging using the AT Protocol. Initially, you can think of it as extra metadata for your blog posts on Bluesky, with more interoperability between platforms possible later.

Is there a reason why we only allow one handle to one DID? I get it as a product decision for bluesky itself, but I don't get it in the context of atproto as an ecosystem. what if I want to be `@taurean.bryant.land` here and `@taurean.work` on a professional service?

Yep. This is what is missing in the ATProto vision. The lexicons should've been a like schema.org instead of domain name-based. Everyone who wants to improve it can discuss it, similar to, well, schema.org. The frontend must be separate from the content. It's beneficial in many ways.

There are some questions about this service, especially since it seems to be from Bluesky (the company): -> github.com/bluesky-social/account-info Is this supposed to be a generic atproto service? Does this "promote" or "ossify" the Blueksy account lexicon now deeply into atproto as the canonical "account"?

stansite is not like other lexicons, they’re distribution/discovery lexicons, not content lexicons. they have canonical locations on the web hence why we even care if a document or publication is verified keep treating them as the data and people will stop using them …and atproto loses imo