4 ms·

What's the difference between Plume and Mastodon? edit: nvm I see that Mastodon is more like twitter. I don't think I really understand why I'm having to creat

What's the difference between Plume and Mastodon? edit: nvm I see that Mastodon is more like twitter. I don't think I really understand why I'm having to create separate accounts on each instance if they can all communicate with each other?

yogthos 7y ago
Communication happens at server level where different instances can choose to federate with one another. Your account lives on a particular server along with the data associated with it such as your posts.
kick 7y ago
ActivityPub is a protocol that does very little with a whole lot of words in the spec. Accounts are not federated, there's no reasonable way of automating your switch to another server assuming yours dies, so forth, so on. Mastodon has a feature claiming to do the last one, but it doesn't actually work, because it's not backwards compatible and only works with relatively modern Mastodon instances (which most are not). Also, you don't really a heavy expectation of privacy using ActivityPub. It's very trust-based, and not in the good way. A lot of the function of ActivityPub would be better served by RSS feeds, the rest would probably be better served on a protocol like Zot; Diaspora would also give you a better expectation of privacy than ActivityPub. Zot, though, fixes basically all of those problems, and is really pretty cool. You have one identity that you can use everywhere, all of your followers come with you because it wasn't an afterthought, access control actually does control access, so on, so on.
- AsyncAwait 7y ago
  It's precisely like e-mail. Would you say email's not federated?
  - fauigerzigerk 7y ago
    The way it works with email is that I create an MX record on the DNS server to tell people where mail for *@mydomain.com should go. When I switch email hosters, I change that MX record. The downside is that it only works for the domain as a whole but not for individual email addresses. Does ActivityPub have something like this as well?
    - AsyncAwait 7y ago
      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.
  - kick 7y ago
    Electronic mail accounts are not federated, which was my claim.
osdev 7y ago
Accounts (I believe ) are similar to email addresses. So it's like having an account userX@gmail.com and trying to migrate that to userX@yahoo.com. Essentially the account is tied to the domain/server.

yogthos 7y ago

Communication happens at server level where different instances can choose to federate with one another. Your account lives on a particular server along with the data associated with it such as your posts.

kick 7y ago

ActivityPub is a protocol that does very little with a whole lot of words in the spec. Accounts are not federated, there's no reasonable way of automating your switch to another server assuming yours dies, so forth, so on. Mastodon has a feature claiming to do the last one, but it doesn't actually work, because it's not backwards compatible and only works with relatively modern Mastodon instances (which most are not). Also, you don't really a heavy expectation of privacy using ActivityPub. It's very trust-based, and not in the good way. A lot of the function of ActivityPub would be better served by RSS feeds, the rest would probably be better served on a protocol like Zot; Diaspora would also give you a better expectation of privacy than ActivityPub. Zot, though, fixes basically all of those problems, and is really pretty cool. You have one identity that you can use everywhere, all of your followers come with you because it wasn't an afterthought, access control actually does control access, so on, so on.

AsyncAwait 7y ago
It's precisely like e-mail. Would you say email's not federated?
- fauigerzigerk 7y ago
  The way it works with email is that I create an MX record on the DNS server to tell people where mail for *@mydomain.com should go. When I switch email hosters, I change that MX record. The downside is that it only works for the domain as a whole but not for individual email addresses. Does ActivityPub have something like this as well?
  - AsyncAwait 7y ago
    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.
- kick 7y ago
  Electronic mail accounts are not federated, which was my claim.

osdev 7y ago

Accounts (I believe ) are similar to email addresses. So it's like having an account userX@gmail.com and trying to migrate that to userX@yahoo.com. Essentially the account is tied to the domain/server.