[Atp] Re: Basic Objectives/Requirements

[Eric Rescorla <[e-mail]>]

Emilia,

I don't think I'm suggesting boxing the work into microblogging. As I said,
I think
this is a non-exhaustive list. The reason I mention microblogging here
specifically
is that it's the largest scale deployment and therefore a good test for
whether
the protocol actually delivers on scalability and interoperability.

-Ekr


On Wed, Nov 5, 2025 at 11:00 AM Emelia S. <[e-mail]> wrote:

> Hi Eric, all,
>
> Having worked on ActivityPub related things for the past few years, and
> then Solid
> before that, I'd strongly discourage a direction that boxes the protocol
> into just doing
> microblogging.
>
> AT Protocol is already so much more than microblogging, so this list of
> interoperability
> isn't, imo, a good list to target. Instead of focusing on just one
> use-case, it'd be better to
> look at all the things we're currently doing today with AT Protocol, and
> where other
> protocols have had growth issues, and to learn from that. Everyone
> building to target
> microblogging as an audience results in a less diverse ecosystem, where
> you essentially
> build for the lowest common denominator of the protocol.
>
> Points C & D are already possible today, B and A are also already possible
> today,
> however, just not widely done.
>
> I haven't yet had a chance to catch up on the full BoF talks yet, but I
> agree with the
> approach of focusing on the repositories and firehose as the first
> deliverables under
> standardization. I would like to see the OAuth Profile and Handles also as
> a deliverable
> soon afterwards though, since OAuth enables the ecosystem to build all
> these
> interesting applications securely.
>
> Yours
> Emelia Smith
>
> @thisismissem.social
>
> On 5 Nov 2025, at 15:34, Eric Rescorla <[e-mail]> wrote:
>
> I've been reviewing the various drafts and I'd like to take a stab at
> laying out what I think what I think some basic (and non-exhaustive)
> requirements are for a standardized system of this type. This is not
> to take a position on whether AT does or does not deliver on these
> objectives, but only one what we're trying to do.
>
>
> # Interoperability
>
> It should be possible based on the eventual set of specifications for
> one or more new entity to stand up their own Web site and/or end-user
> clients that:
>
> (a) Provide similar functionality to bsky.app (or X or Mastodon for
>     that matter)
> (b) Can access the same set of content as appears on bsky.app and can
>     refer to content on bsky.app and be referred to by that content.
> (c) Do not use any infrastructure operated by BlueSky.
> (d) Does not require any permission from BlueSky.
>
>
> # Scalability
>
> It should be possible for a user to provide content to the system at a
> cost that is roughly constant in the number of people consuming that
> content. This is different from the Web where the load on your server
> is roughly linear in the number of people consuming your content, but
> similar to existing social systems, where it doesn't cost you
> personally more if your posts become popular. As an intuition pump, I
> should be be able to operate a PDS on raspberry pi no matter how many
> people want to consume and/or respond to to my content.
>
> Hopefully we can agree on these. If not, that's an important thing to
> discuss.
>
> -Ekr
>
>
>
>
> _______________________________________________
> Atp mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
>
>