The #ActivityPub protocol is often compared to email with its actor inboxes and outboxes.

[smallcircles@social.coop]

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.

https://github.com/swicg/activitypub-api/issues/66#issuecomment-4124959526

[silverpill@mitra.social]

@smallcircles Fediverse is not like email because ActivityPub has many different message types. What kind of client API developers use is irrelevant.

[smallcircles@social.coop]

@silverpill

@delta might like to have a word with you. 😅

I did not try to make the literal comparison between a person who emails or creates email-related software with #fediverse AP solution development.

What I did want to point out was how blurred the lines are in the #ActivityPub fediverse between stuff that is the protocol, and stuff that is solution development i.e. app-specific / domain-specific.

The anti-patterns I listed are encountered by any newcomer dev who takes an interest in creating fedi apps & services, and is faced with much more than they bargained for when reading the AS/AP specs.

It forms a barrier to entry, decrease in attractiveness to create fedi apps, and devs leaving the space for greener pastures (e.g. to #ATProto or various still-less-mature-than-fedi #P2P protocols)

[smallcircles@social.coop]

@silverpill

There are a couple of #ActivityPub projects that focus on providing the good tools that abstract away the complexities of wire-level network comms, and help free the hands of a solution developer to focus more directly on what people need, instead of on plumbing and Babylonian speech confusion of how things fit together. I try to emphasize these projects, e.g. @fedify by listing them higher in the https://delightful.coding.social curated lists.

But their challenge is to offer a kind of reverse to browser quirks mode. Web browsers can handle about any malformed HTML a person throws at it, and still manage to turn that into machine processable form, and make the most of it.

As a fedi toolkit builder you almost need to do the opposite. Focus on offering comprehensive and intuitive API's and functionality to solution developers, and translate it into wire chaos that constitutes the fediverse-protocol-of-the-day.

[delta@chaos.social]

@smallcircles @silverpill @fedify that's probably an interesting discussion to have. As far as https://chatmail.at efforts are concerned, we are using SMTP in very dumbed down manner because it's all about relaying E2EE messages with no metadata. All logic is in the client, where however https://github.com/chatmail/core/blob/main/standards.md and https://github.com/chatmail/core/blob/main/spec.md come into play. Bot or client are recommended to use the "deltachat-rpc-server" which implements the spec and ietf standards, simplifying coordination.

[silverpill@mitra.social]

@smallcircles

There are a couple of #ActivityPub projects that focus on providing the good tools that abstract away the complexities of wire-level network comms

You're talking to a developer of such project.

There is no "wire chaos", where did you get this idea from?

@fedify