[Atp] Re: Basic Objectives/Requirements

["Emelia S." <[e-mail]>]

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 <http://bsky.app/> (or X or Mastodon for
>     that matter)
> (b) Can access the same set of content as appears on bsky.app <http://bsky.app/> and can
>     refer to content on bsky.app <http://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]