Rabble about twitter, history and activitypub

“Scaling twitter became the priority. We did get oAuth and ActivityPub out of those early hackathons at O’Reilly Media organized foocamps. The open api meant that a federated twitter wasn’t needed, until the api got closed, of course.”

via @bengo

1 Like

Twitter is important. It matters, and we care about it in ways that are very different from most companies, or even most tech platforms.

I honestly couldn’t bring myself to read past this line. I never once cared about Twitter. And I watched it’s birth when I used to still watch Old Media. The reason Twitter became what it is, is because Old Media sold it to the brainwashed public. They sold it as a way that people get to talk back to the talking heads.

I never cared about any of that shit. And I never once believed what they were selling. That’s why I never gave a flying fuck about Twitter. And never will.

YMMV.

3 Likes

ActivityPub was made during the Social Web Working Group (I think he might mean activity streams 1.0)

It’s was great in that it gave us mastodon which really kick started the fediverse

The eco system would possibly benefit from a full modern upgrade, based on implementation experience:

  • include full PKI
  • C2C / C2S / S2S all as first class
  • lightweight spec for easy implmentation
  • lightweight vocabs, not dependent on huge infrastructure
  • vocabs as optional based on maturity, and with real, practical, version control
  • client side apps as first class, less reliance on large servers
  • read/write standards so that users can easily persist content
  • multi protocol transport, rather than HTTP only
  • realtime protocol for updates, chat, presence etc.
  • lightweight digital signatures
  • payments infrastructure that does not favour proprietary solutions e.g. lightning addresses + alby extenstion
  • micro services and micro profiles that can be self hosted
  • human and machine readable data, machine publishing
  • censorship resistance via multiple data stores / relays
  • web contracts where commitments can be made and fulfilled in JS
  • ability to evolve content including nomadic identity
2 Likes

Mastodon was a (very) minor evolution on pump.io and gnu social, and leveraged the gnu social user base to claim largesse and majority, thus derailing the ActivityPub standards process and basically nixing all the things you listed in an effort to become the de facto fedi clone of Twitter (and in particular TweetDeck).

All of the things you list were also well known and well defined technologies at the time of the ActivityPub process. Just FYI.

Mastodon was a regression and in many ways a sabotage, not progress.

I think it’s a good idea not to turn ActivityPub into a suitcase of all the things. To keep it fairly concise and focussed on an email-style architecture.

Although it would be possible to make a chat app with ActivityPub, the existing chat systems work well enough and have had many years of refinement. ActivityPub should probably remain a non-realtime email-like system.

ActivityPub was designed to be a briefcase for all the things. That’s why it’s underpinned by JSON-LD.

The confusion enters when Mastodon tried to turn everything into CRUD activities on Note objects.

I agree with @rialtate here, though I think it is better to discern between ActivityStreams and ActivityPub here. AS offers social primitives to be exchanged via AP protocol in email-like manner, and through its Linked Data extensibility mechanism AS can be extended with custom vocabs to create different app types / enter different business domains (areas of expertise).

That said…

I also agree with this. There’s a range of applications / domains where the use of AS/AP is appropriate and others where it is not. Chat is an example where one might start scratch their head and wonder if it is well-suited or not. When it comes to more real-time (‘chatty’) communications, say Collaborative Doc Editing, or IoT sensor devices, etc. then its clearly no good choice at all.

But I still think there’s a very broad range of different app types where AS/AP can be used. All involving user-initated social interactions of some kind or other, that can be captured well in message exchanges.