My position on ATProto, as a protocol, is that the Good Part is the PDS¹.

[mcc@mastodon.social]

@cwebber also the thing I see the PDS as providing at root is "a standard API for requesting data objects by key". a blog isn't that, you can address it by key (URL) but it returns formatted HTML not a data representation. RSS isn't that either, RSS is a linear recency-biased stream, and anyway we don't want RSS we want ActivityPub. You could expose the PDS xrpcs from Wordpress with a plugin the same way you can add ActivityPub to WordPress with a plugin.

[cwebber@social.coop]

@mcc That's a reasonable one, to have a content-addressing retrieval endpoint!

[mcc@mastodon.social]

@cwebber But also, WordPress is a horrible, security-vulnerability-infested nightmare to maintain, and the BlueSky PDS is easy and resource-cheap to maintain, so I'd rather have (and eventually, will write) PDS with a wordpress-like frontend than WordPress with a PDS-like frontend

[cwebber@social.coop]

@mcc yeah but that's not really a compelling argument for the *protocol*

[trwnh@mastodon.social]

@mcc @cwebber arguably the concept of storing data is not new, no -- although you do get some benefits from the merkle tree stuff

imo the real value is in lexicons as a way to coordinate conventions. a lot of this boils down to "reverse dns namespace" but there is a very well-known problem in e.g. solid where everyone can interface with the storage pods (~pds) but no one knows how to agree on where things should be stored. example: do you store birthdays in your contact book or your calendar?

[mcc@mastodon.social]

@trwnh @cwebber however also
- i think some previous systems, like protobuf, did this already, and
- at the same time they introduce the concept of the "lexicon" they poison it, by using the "schema" to absolutely, positively, in any bluesky-derived system, ban microblog posts with more than 300 characters. so the lexicon is good but you don't want to use it or you are limited to 300 characters

EDIT: typed the wrong word. the first time.

[trwnh@mastodon.social]

@mcc @cwebber that's a problem with the schema being 1) too strict, 2) entirely vertically controlled by bsky as an "app" vertical

a looser schema based on consensus standards instead of apps would probably be better in the long term

[trwnh@mastodon.social]

@mcc the web has 5 billion users and i'm the only one on my website. we really ought to be looking at how to establish identity, auth, etc cross-site on the web instead of tying it all up into platforms...

[mcc@mastodon.social]

@trwnh Yeah. Hence the power of DID. Except that we've sorta poisoned DID now by introducing a half-solution, did:plc, which is fundamentally unacceptable but which is better to do better than from an end-user perspective.

The thing that upsets me about bluesky is it's not a very good solution but it is situated in the market in a way that makes it socially difficult to introduce better solutions.

[trwnh@mastodon.social]

@mcc one thing that bothered me about that "open social" article that was going around earlier is that it dismisses personal websites as somehow not supporting aggregation, which is ridiculous because there are multiple ways to aggregate data from websites

i really think you could do a lot of this stuff on websites with existing tech, you just need to be able to negotiate identity and access control. like imagine just using HTTP (WWW-Authenticate header, *fully* define an auth scheme...) for it

[fluffy@plush.city]

@trwnh @mcc This is one of the big goals of the IndieWeb initiative, and something I've been trying really hard to support for years now.

IndieAuth is a pretty good identity/auth spec. TicketAuth is at least in principle a good way of providing automation for feed readers (although nobody supports it as a consumer, and only a handful support it as a publisher). The lack of adoption outside of IndieWeb is frustrating to see.

[fluffy@plush.city]

@trwnh @mcc but like the short version of both IndieAuth and TicketAuth is granting authority to whoever has control over a particular URL, and lightweight mechanisms for proving that they have that control. Both are, in my experience, super easy to implement.

[trwnh@mastodon.social]

@fluffy @mcc i know i talked about how you could handle identity at the level of the http request (advertise an auth-scheme in your www-authenticate header, provide a valid authorization header using that auth-scheme)

but you could also just establish a local session on a site by proving you control some other id, which gets linked to the local id. it's exactly the indieauth idea, "me on github == me on site.example == me on your site" (if you use local accounts, it's basically a credential)

[fluffy@plush.city]

@trwnh @mcc Yeah that's more or less what IndieWeb calls RelMeAuth, although actually implementing that can lead to a lot more complexity because you have to then be able to verify the stated relationship, which usually means having to manage a bunch of OAuth client credentials.

Mastodon uses the weaker form of RelMeAuth (i.e. seeing that there's reciprocal rel="me" links between URLs) for the profile verification but that doesn't help with request-level security.

[fluffy@plush.city]

@trwnh @mcc Come to think of it, I wonder if something like LetsEncrypt's ACME protocol could be used for this use case.

[mcc@mastodon.social]

@fluffy @trwnh I mean also DNS is a brittle and extremely censorable system. A cryptographic key like plc uses would be better, if you had a way of looking it up other than kinda reproducing DNS circa 1995

[trwnh@mastodon.social]

@mcc @fluffy "keyservers except there is only one of them" sure is a model huh