The #ActivityPub protocol is often compared to email with its actor inboxes and outboxes.
However email allows emailers to email without knowing anything about how SMTP works under the hood. Using friendly tools you can construct newsletters, order receipts, invoices, etc. and send them to addressees. Fire and forget, and if it was undeliverable you receive notice. The network mechanics are a black box.
Here the #fediverse significantly differs. Solution developers (emailers) creating apps and services must not only become protocol experts (handle SMTP) but deal with ugly wire reality (self-hosting email), then do whack-a-mole maintenance against moving release targets to fix app-by-app breakages and protocol decay. That is like if I send an email, it may break yours.
The ActivityPub API initiative + task force offer GREAT opportunity to improve things. A greenfield #ATProto-like start to realign with the original promise and power of AS/AP based social web.
Protocol design · Issue #66 · swicg/activitypub-api
(This issue is created in follow-up of #63 Avoid misconception and #4 Rate limiting, and related fedi thread.) Avoiding misconceptions: What is a profile? I think my overarching concern is that the ActivityPub API specification doesn't b...
GitHub (github.com)
