ActivityPub strikes me as the invention of people who believe that the internet = HTTP, and who know about JSON but not RFC822.
Some of the example message bodies just look like JSON-ized SMTP headers, “inReplyTo” etc. It looks like it has a MIME-inspired “mediaType” attribute too, but does it allow only one media type per message?
Can someone who is more familiar with ActivityPub give me the sales pitch about why existing protocols don’t suffice?
RFC822 is ASCII only to begin with one of the biggest limitations of email related “standards”.
Some 6.5 billion people around the globe use non-ascii charecters, and old standards only have layers of hacks upon them to support their usecases to some extent.
Why not create new standards from the ground up for the current usecases? I’m not interested in ActivityPub curently, but I have some experience with email and related technologies, and it badly needs a redesign. It won’t happen as none of the parties capable to organise it is interested in it.
My uninformed guess is that with the slow decline of email, there are more & better JSON parsers than there are MIME or email parsers. I would have made the same choice, but my reason would have revolved around JSON’s ability to store structured data, for future flexibility.
HTTP Headers are the same format like MIME headers, browsers already have everything one would need for mail. Multipart documents (email attachments) are the same format like HTTP file uploads via form. There is a number of headers both share.
I think it comes down to tooling. Protocol A could be 10x as widely deployed as protocol B, but if protocol B has better libraries, I’ll give that more weight in my decision of which to use. I had to assemble a multipart MIME message for work a few weeks ago, and everything about the experience was inferior to “create a data structure and convert it to JSON”.
Coders are likely to pick the easiest path, if everything else is roughly equal.
SMTP is forever tainted by spam. ISPs like to block ports, spam filters like to eat mail from new unknown servers, etc.
Giving a pitch for Webmention instead of ActivityPub: Webmention requires the sender to publish an html page that actually links to the target URL. You can be stricter and require a valid microformats2 reply/like/repost/bookmark. That already stops old school pingback spam. For stronger protection, there are clever schemes based on “this non-spam domain you linked to has linked to me”.
The nice thing about the activity stream spec is that it can capture many different types of interaction. Writing a blogpost, sending an email, listening to a song, sharing something etc. All of these are easy to model so its a very general spec.
I like the tech, it’s just that distributed protocols are struggling at the moment. I doubt it will succeed.
The problem is that the spec doesn’t specify what you are supposed to do with these activities beyond some very basic things, so essentially the first implementation of a certain object type (e.g. ‘Video’ for peertube) becomes the ‘standard’ that isn’t documented anywhere.
Too bad the spec is not appealing. I have a hobby project that requires it, but it’ll take time to draw schemas of interactions between spec’s components. And I’m thinking more of social web protocols as a whole.
I understand that to add layers on top of HTTP is not the lighter way, but I’d like to see the email protocols (SMTP…) be replaced by these new web protocols. At least for registration on 3rd party services, which is one of the most used use of emails nowadays.
Spec: https://www.w3.org/TR/activitypub/
ActivityPub strikes me as the invention of people who believe that the internet = HTTP, and who know about JSON but not RFC822.
Some of the example message bodies just look like JSON-ized SMTP headers, “inReplyTo” etc. It looks like it has a MIME-inspired “mediaType” attribute too, but does it allow only one media type per message?
Can someone who is more familiar with ActivityPub give me the sales pitch about why existing protocols don’t suffice?
RFC822 is ASCII only to begin with one of the biggest limitations of email related “standards”.
Some 6.5 billion people around the globe use non-ascii charecters, and old standards only have layers of hacks upon them to support their usecases to some extent.
Why not create new standards from the ground up for the current usecases? I’m not interested in ActivityPub curently, but I have some experience with email and related technologies, and it badly needs a redesign. It won’t happen as none of the parties capable to organise it is interested in it.
My uninformed guess is that with the slow decline of email, there are more & better JSON parsers than there are MIME or email parsers. I would have made the same choice, but my reason would have revolved around JSON’s ability to store structured data, for future flexibility.
HTTP Headers are the same format like MIME headers, browsers already have everything one would need for mail. Multipart documents (email attachments) are the same format like HTTP file uploads via form. There is a number of headers both share.
I think it comes down to tooling. Protocol A could be 10x as widely deployed as protocol B, but if protocol B has better libraries, I’ll give that more weight in my decision of which to use. I had to assemble a multipart MIME message for work a few weeks ago, and everything about the experience was inferior to “create a data structure and convert it to JSON”.
Coders are likely to pick the easiest path, if everything else is roughly equal.
No reason, really. It’s a marketing effort, mostly.
SMTP is forever tainted by spam. ISPs like to block ports, spam filters like to eat mail from new unknown servers, etc.
Giving a pitch for Webmention instead of ActivityPub: Webmention requires the sender to publish an html page that actually links to the target URL. You can be stricter and require a valid microformats2 reply/like/repost/bookmark. That already stops old school pingback spam. For stronger protection, there are clever schemes based on “this non-spam domain you linked to has linked to me”.
The nice thing about the activity stream spec is that it can capture many different types of interaction. Writing a blogpost, sending an email, listening to a song, sharing something etc. All of these are easy to model so its a very general spec.
I like the tech, it’s just that distributed protocols are struggling at the moment. I doubt it will succeed.
The problem is that the spec doesn’t specify what you are supposed to do with these activities beyond some very basic things, so essentially the first implementation of a certain object type (e.g. ‘Video’ for peertube) becomes the ‘standard’ that isn’t documented anywhere.
Too bad the spec is not appealing. I have a hobby project that requires it, but it’ll take time to draw schemas of interactions between spec’s components. And I’m thinking more of social web protocols as a whole.
I understand that to add layers on top of HTTP is not the lighter way, but I’d like to see the email protocols (SMTP…) be replaced by these new web protocols. At least for registration on 3rd party services, which is one of the most used use of emails nowadays.