3 ms·

There's no support for messages addressed to @mastodon.xyz to really point to @social.me directly, unless you do some server-side tricks yourself. But the simi

There's no support for messages addressed to @mastodon.xyz to really point to @social.me directly, unless you do some server-side tricks yourself. But the similarity to email is in that accounts are not federated. xyz@gmail.com is an independent email, including storage, from xyz@outlook.com - might be a different person entirely. The 'federated' part of email is that xyz@gmail.com can send email to xyz@outlook.com, practically as if both were on the same server. This is what ActivityPub does for social networking.

fauigerzigerk 7y ago
Right, so I think there are actually two separate issues here. One is federation, which is similar between email and ActivityPub as you point out. The other is user identity. That's the part where email appears to be more flexible by relying on DNS to seperate user identity from email hosting (for the small minority of users who own their domain name). Section 3.1 of the ActivityPub spec says that objects (I think this includes users) are identified by "publicly dereferencable URIs, such as HTTPS URIs, with their authority belonging to that of their originating server" [1]. Now, I wonder if an "originating server" is actually required or if it's sufficient to control the domain to which this URI belongs. It seems to me that it should be rather simple for ActivityPub implementations to support a mechanism similar to MX records. For instance, TXT records could be used to achieve the same thing. [1] https://www.w3.org/TR/2018/REC-activitypub-20180123/#obj-id https://www.w3.org/TR/2018/REC-activitypub-20180123/#obj-id
- AsyncAwait 7y ago
  Yes, you're right that email is more flexible here, however the issue is that lets say you have your own domain name, but use fastmail. If you loose your fastmail for whatever reason and didn't have backups, you get to keep your email identity if you point your MX to a new provider, which means people can still contact you, but you won't have any of your old email. ActivityPub servers could do something similar here and in fact Mastodon in a sense supports this, (as you point out, the Actor's identity is essentially the URL of their profile, which could change host), but the problem then becomes that old interactions with the user will have 'ghost replies'. Understandably, as far as I know to save on storage and improve response times, not every interaction a user has on the fediverse with different users is copied to his/her server, that is replies in a thread from different users on different servers are still stored on their servers. Therefore if someone in a thread deletes their server, their responses/interactions will essentially disappear to anyone viewing that thread, so I might be replying to something a user said, but you won't be able to see what I am replying to etc. Mastodon supports import/export, so that an Actor/user should be able to move servers and as long as they import their toots+followers + use the same domain, you shouldn't notice a difference, but I don't believe this is supported by the protocol directly.

fauigerzigerk 7y ago

Right, so I think there are actually two separate issues here. One is federation, which is similar between email and ActivityPub as you point out. The other is user identity. That's the part where email appears to be more flexible by relying on DNS to seperate user identity from email hosting (for the small minority of users who own their domain name). Section 3.1 of the ActivityPub spec says that objects (I think this includes users) are identified by "publicly dereferencable URIs, such as HTTPS URIs, with their authority belonging to that of their originating server" [1]. Now, I wonder if an "originating server" is actually required or if it's sufficient to control the domain to which this URI belongs. It seems to me that it should be rather simple for ActivityPub implementations to support a mechanism similar to MX records. For instance, TXT records could be used to achieve the same thing. [1] https://www.w3.org/TR/2018/REC-activitypub-20180123/#obj-id https://www.w3.org/TR/2018/REC-activitypub-20180123/#obj-id

AsyncAwait 7y ago
Yes, you're right that email is more flexible here, however the issue is that lets say you have your own domain name, but use fastmail. If you loose your fastmail for whatever reason and didn't have backups, you get to keep your email identity if you point your MX to a new provider, which means people can still contact you, but you won't have any of your old email. ActivityPub servers could do something similar here and in fact Mastodon in a sense supports this, (as you point out, the Actor's identity is essentially the URL of their profile, which could change host), but the problem then becomes that old interactions with the user will have 'ghost replies'. Understandably, as far as I know to save on storage and improve response times, not every interaction a user has on the fediverse with different users is copied to his/her server, that is replies in a thread from different users on different servers are still stored on their servers. Therefore if someone in a thread deletes their server, their responses/interactions will essentially disappear to anyone viewing that thread, so I might be replying to something a user said, but you won't be able to see what I am replying to etc. Mastodon supports import/export, so that an Actor/user should be able to move servers and as long as they import their toots+followers + use the same domain, you shouldn't notice a difference, but I don't believe this is supported by the protocol directly.