New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Follower Migration #1

Open
sandhawke opened this Issue May 5, 2017 · 51 comments

Comments

Projects
None yet
@sandhawke

sandhawke commented May 5, 2017

How can a user switch from being chris@host1.example to chris@host2.example without losing their followers?

Related problem is how can they avoid breaking all the incoming links. If their followers were just polling their outbox, then this would be a sub-problem of that, but in general it might be different. For this issue, in this context, let's be protocol agnostic, ie OStatus, ActivityPub, etc, etc. Consider raising separate issues on individual protocol repos, but discussing common aspects here.

Some variations:

  • Is host1 going to remain around, and be willing for forward for 90 days, or even years, or will it be dropping off the net or shutting down with no warning, or only a few days warning?
  • Is this initiated by Chris, wanting to leave host1, or by host1, wanting to move its users to host2? Does that affect the protocol at all?
  • What if this was initiated by someone pretending to be Chris, hijacking the followers? Would Chris have any recourse whatsoever? (issue raised by @Gargron)
  • Can it be temporary? Some protocols might break if after a few hours or months, Chris wanted to move back to host1.
  • Can users be split, so followers of chris@host1.example end up automatically following both chris-work@host2.example and chris-play@host2.example ?

In the world of email, this is usually done by either automatic forwarding or bouncing. With forwarding, email that arrives to chris@host1.example gets sent on to chris@host2.example. That works as long as host1 remains operational and willing to do this. With bouncing, host1 sends an error reply back to the sender, telling them to use the different email. That also only works while host1 is able & willing, but is more likely to make senders change their records so they send to the new address and no longer rely on host1.

With phone numbers, traditionally people who switched phone number could requested that the old number have a recording that told callers to use the new number. The recording might last a pre-set time (eg 1-year) or until the phone company wanted to reuse the number. This is like an email bounce message. More recently, number "portability" has become an option, where users can transfer their number to a different provider. That seems to align with the social-web case of users using their own domain name, in which case they likely have portability, and no need to solve this problem.

@nightpool

This comment has been minimized.

Show comment
Hide comment
@nightpool

nightpool May 5, 2017

the brief, 10,000-foot overview: the issue has an actual description now, see above.

The below is preserved for posterity

  1. I sign up for an account on activitypub server A
  2. I get a lot of followers there, I make a lot of posts, have a great time
  3. I then decide that I don't like activitypub server A for whatever reason, and I want to move to activitypub server B
  4. ideally, I would be able to keep the amount of people who follow me, and maybe(?) even keep the posts that I've made (from my experience with users, the first is critical, the second is nice-to-have)

nightpool commented May 5, 2017

the brief, 10,000-foot overview: the issue has an actual description now, see above.

The below is preserved for posterity

  1. I sign up for an account on activitypub server A
  2. I get a lot of followers there, I make a lot of posts, have a great time
  3. I then decide that I don't like activitypub server A for whatever reason, and I want to move to activitypub server B
  4. ideally, I would be able to keep the amount of people who follow me, and maybe(?) even keep the posts that I've made (from my experience with users, the first is critical, the second is nice-to-have)
@cwebber

This comment has been minimized.

Show comment
Hide comment
@cwebber

cwebber May 5, 2017

Collaborator

Doing this would require some sort of dual ACK from both ends that yes, this move is expected I think.

Collaborator

cwebber commented May 5, 2017

Doing this would require some sort of dual ACK from both ends that yes, this move is expected I think.

@sandhawke

This comment has been minimized.

Show comment
Hide comment
@sandhawke

sandhawke May 5, 2017

Sorry for the delay; proper opening issue description added now.

sandhawke commented May 5, 2017

Sorry for the delay; proper opening issue description added now.

@sandhawke

This comment has been minimized.

Show comment
Hide comment
@sandhawke

sandhawke May 5, 2017

Gargron's concern, and then writing the issue description, made me realize this is more complicated than I thought.

Possible solution: a message type saying { X is moving to Y, Z, ..., starting at time T1, optionally ending at time T2 , and maybe including a human-readable explanation}.

Recipients of this message should be somewhat skeptical, aware of possible problematic situations.

If you get this message from X, then it's probably legit, but keep checking X for a while (30 days?) to make sure the forwarding message remains, and hasn't be modified to have ended. If X remains a feed but no longer has the forwarding, alert the user to something suspicious.

If you get this message from W, who you also trust/follow, and you're unable to reach X, then follow Y, Z, but include a warning to your user. If you know a public key for X, and Y has an X-signed statement of the forwarding, then no need to warn users.

That seems to handle most of the use cases sketched out here, I think. Maybe it's too complicated.

sandhawke commented May 5, 2017

Gargron's concern, and then writing the issue description, made me realize this is more complicated than I thought.

Possible solution: a message type saying { X is moving to Y, Z, ..., starting at time T1, optionally ending at time T2 , and maybe including a human-readable explanation}.

Recipients of this message should be somewhat skeptical, aware of possible problematic situations.

If you get this message from X, then it's probably legit, but keep checking X for a while (30 days?) to make sure the forwarding message remains, and hasn't be modified to have ended. If X remains a feed but no longer has the forwarding, alert the user to something suspicious.

If you get this message from W, who you also trust/follow, and you're unable to reach X, then follow Y, Z, but include a warning to your user. If you know a public key for X, and Y has an X-signed statement of the forwarding, then no need to warn users.

That seems to handle most of the use cases sketched out here, I think. Maybe it's too complicated.

@nightpool

This comment has been minimized.

Show comment
Hide comment
@nightpool

nightpool May 5, 2017

@sandhawke any public key would also be considered compromised in the threat model we're sketching out though, right?

nightpool commented May 5, 2017

@sandhawke any public key would also be considered compromised in the threat model we're sketching out though, right?

@sandhawke

This comment has been minimized.

Show comment
Hide comment
@sandhawke

sandhawke May 6, 2017

I should perhaps detail use cases and threat models. The case I'm thinking a pubic key is useful is when you can't do forwarding: the old site goes offline, deletes your account and refuses to forward, or something like that. In that case you ask various friends (W) to publish the move notice and hopefully you put a signed copy of it at your new location. This does require you have your secret key stored somewhere else, basically as an account recovery key.

sandhawke commented May 6, 2017

I should perhaps detail use cases and threat models. The case I'm thinking a pubic key is useful is when you can't do forwarding: the old site goes offline, deletes your account and refuses to forward, or something like that. In that case you ask various friends (W) to publish the move notice and hopefully you put a signed copy of it at your new location. This does require you have your secret key stored somewhere else, basically as an account recovery key.

@nightpool

This comment has been minimized.

Show comment
Hide comment
@nightpool

nightpool May 6, 2017

Also related are these Mastodon issues: tootsuite/mastodon#177 & tootsuite/mastodon#2854

nightpool commented May 6, 2017

Also related are these Mastodon issues: tootsuite/mastodon#177 & tootsuite/mastodon#2854

@jaywink

This comment has been minimized.

Show comment
Hide comment
@jaywink

jaywink May 6, 2017

This is something many decentralized projects have tried to do and AFAIK, from the federated social web, only Hubzilla and Friendica implement in some way. Hubzilla features identities which can live on many servers, making migration unnecessary. Friendica implements AFAIK migration by sending out moved messages (some variant of what is discussed here). Maybe @annando wants to clarify the status of identity migration in Friendica?

For Diaspora (and similar), I wrote a draft spec that actually aimed to solve the problem of dying servers through automated decentralized backup/restore. At the same time it would offer tools to do a migration manually. Parts of the spec re identity migration are WIP in Diaspora currently, though I haven't followed the details on how it is going to be implemented as I never intended to work on it myself and am not active in the project any more.

This would certainly be a nice problem to solve - it is the bane of decentralized social web for users who don't run their own servers. Personally, I find the problem of dying servers more problematic though - that is why I wanted to look at automating the decentralization of the identity.

jaywink commented May 6, 2017

This is something many decentralized projects have tried to do and AFAIK, from the federated social web, only Hubzilla and Friendica implement in some way. Hubzilla features identities which can live on many servers, making migration unnecessary. Friendica implements AFAIK migration by sending out moved messages (some variant of what is discussed here). Maybe @annando wants to clarify the status of identity migration in Friendica?

For Diaspora (and similar), I wrote a draft spec that actually aimed to solve the problem of dying servers through automated decentralized backup/restore. At the same time it would offer tools to do a migration manually. Parts of the spec re identity migration are WIP in Diaspora currently, though I haven't followed the details on how it is going to be implemented as I never intended to work on it myself and am not active in the project any more.

This would certainly be a nice problem to solve - it is the bane of decentralized social web for users who don't run their own servers. Personally, I find the problem of dying servers more problematic though - that is why I wanted to look at automating the decentralization of the identity.

@sandhawke

This comment has been minimized.

Show comment
Hide comment
@sandhawke

sandhawke May 20, 2017

Trying to make short term progress on this, I've created #4 to focus on the narrow case of forwarding, which I suspect will work fine in most cases (although clearly not all).

sandhawke commented May 20, 2017

Trying to make short term progress on this, I've created #4 to focus on the narrow case of forwarding, which I suspect will work fine in most cases (although clearly not all).

@annando

This comment has been minimized.

Show comment
Hide comment
@annando

annando May 20, 2017

@jaywink I totally forgot about this. Friendica is doing it that way:

  • A user has to export his (or her) personal data. This file contains the private key
  • Then the user can create an account on another Friendica server and can upload this file.
  • A "the account has moved" message is now sent to all followers of the former account.
  • Since the same private key is used, the receivers can check that everything is okay.
  • On receiving this "move" message, the contact data is changed to the new address.

annando commented May 20, 2017

@jaywink I totally forgot about this. Friendica is doing it that way:

  • A user has to export his (or her) personal data. This file contains the private key
  • Then the user can create an account on another Friendica server and can upload this file.
  • A "the account has moved" message is now sent to all followers of the former account.
  • Since the same private key is used, the receivers can check that everything is okay.
  • On receiving this "move" message, the contact data is changed to the new address.
@sandhawke

This comment has been minimized.

Show comment
Hide comment
@sandhawke

sandhawke May 20, 2017

@annando do you know if that addresses the URLs for content at all? Do those all break?

sandhawke commented May 20, 2017

@annando do you know if that addresses the URLs for content at all? Do those all break?

@jaywink

This comment has been minimized.

Show comment
Hide comment
@jaywink

jaywink May 20, 2017

Friendica is doing it that way:

OK so exactly the same as what was proposed for Diaspora, except for the automated backup part. For federated networks I think this is a good way to go. Simply redirecting users will not help those instances which have at some point received updates from the user before and have local data cached. A moved message makes sense to bring all contacts in the network up to date. This is where things like the relay system and user search platforms (which for example Nextcloud is planning) would help too, to ensure the moved message is sent out wide.

What is the maturity of Friendica user migration - is it stable and used often?

jaywink commented May 20, 2017

Friendica is doing it that way:

OK so exactly the same as what was proposed for Diaspora, except for the automated backup part. For federated networks I think this is a good way to go. Simply redirecting users will not help those instances which have at some point received updates from the user before and have local data cached. A moved message makes sense to bring all contacts in the network up to date. This is where things like the relay system and user search platforms (which for example Nextcloud is planning) would help too, to ensure the moved message is sent out wide.

What is the maturity of Friendica user migration - is it stable and used often?

@annando

This comment has been minimized.

Show comment
Hide comment
@annando

annando May 20, 2017

There are some issues with the migration - but is is working.

annando commented May 20, 2017

There are some issues with the migration - but is is working.

@annando

This comment has been minimized.

Show comment
Hide comment
@annando

annando May 20, 2017

@sandhawke I don't understand. What do you mean?

annando commented May 20, 2017

@sandhawke I don't understand. What do you mean?

@sandhawke

This comment has been minimized.

Show comment
Hide comment
@sandhawke

sandhawke May 20, 2017

@annando I don't know how Friendica works. Do posts have URLs (aka permalinks)? If so, then I'm asking what happens to a post I make hosted on site A when I move to site B. Are my posts now gone? If posts don't have URLs, then the question is a little weirder, but basically is all the content I produced, long ago, on a different host that's been gone for years -- the posts, the likes, the replies, still out there and working fine, after I move to a different site?

sandhawke commented May 20, 2017

@annando I don't know how Friendica works. Do posts have URLs (aka permalinks)? If so, then I'm asking what happens to a post I make hosted on site A when I move to site B. Are my posts now gone? If posts don't have URLs, then the question is a little weirder, but basically is all the content I produced, long ago, on a different host that's been gone for years -- the posts, the likes, the replies, still out there and working fine, after I move to a different site?

@annando

This comment has been minimized.

Show comment
Hide comment
@annando

annando May 21, 2017

The old posts aren't gone, only the contact name changes. Posts are having an URL, but that only points to the guid, see here for an example: https://pirati.ca/display/735a2029205920ea17dbae8771484681

If that user would decide to move to another server than that link would stay the same, only the names would be changed.

annando commented May 21, 2017

The old posts aren't gone, only the contact name changes. Posts are having an URL, but that only points to the guid, see here for an example: https://pirati.ca/display/735a2029205920ea17dbae8771484681

If that user would decide to move to another server than that link would stay the same, only the names would be changed.

@sandhawke

This comment has been minimized.

Show comment
Hide comment
@sandhawke

sandhawke May 21, 2017

So, if the author left pirati.ca, that URL ("https://pirati.ca/display/735a2029205920ea17dbae8771484681") would become 404 or domain-not-found or maybe offer some other content, but in theory someone could know how to re-write it, changing the domain name to your new location, and then I could get the content? Am I understanding right?

sandhawke commented May 21, 2017

So, if the author left pirati.ca, that URL ("https://pirati.ca/display/735a2029205920ea17dbae8771484681") would become 404 or domain-not-found or maybe offer some other content, but in theory someone could know how to re-write it, changing the domain name to your new location, and then I could get the content? Am I understanding right?

@annando

This comment has been minimized.

Show comment
Hide comment
@annando

annando May 21, 2017

No, not really. The content under https://pirati.ca/display/735a2029205920ea17dbae8771484681 you will find under https://squeet.me/display/735a2029205920ea17dbae8771484681, https://friendica.mrpetovan.com/display/735a2029205920ea17dbae8771484681 and under similar urls at some more Friendica servers.

Every message has a guid, in this case it is "735a2029205920ea17dbae8771484681". This identifies the message. Additionally every Friendica message has got an uri. That contains the hostname. But that isn't changed after the relocation.

The relocation message only changes the contact data at all Friendica servers - but the message and the path to the message will stay the same.

annando commented May 21, 2017

No, not really. The content under https://pirati.ca/display/735a2029205920ea17dbae8771484681 you will find under https://squeet.me/display/735a2029205920ea17dbae8771484681, https://friendica.mrpetovan.com/display/735a2029205920ea17dbae8771484681 and under similar urls at some more Friendica servers.

Every message has a guid, in this case it is "735a2029205920ea17dbae8771484681". This identifies the message. Additionally every Friendica message has got an uri. That contains the hostname. But that isn't changed after the relocation.

The relocation message only changes the contact data at all Friendica servers - but the message and the path to the message will stay the same.

@sandhawke

This comment has been minimized.

Show comment
Hide comment
@sandhawke

sandhawke May 21, 2017

Okay, I could ask lots of followup questions, but I think I get the gist, thanks. It seems to me, it's not very webby, which makes this issue easier to solve.

sandhawke commented May 21, 2017

Okay, I could ask lots of followup questions, but I think I get the gist, thanks. It seems to me, it's not very webby, which makes this issue easier to solve.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost May 22, 2017

Don't really know what you mean by "webby" so can't respond to that.

In the Hubzilla implementation, identity is separate from DNS location. The DNS location is basically "where I am right now" and not "who I am". Content changes and friendship changes are replicated across different channel instances, and site-specific internal links (say photos and attachments in a post, etc.) adjusted accordingly. This started with a very simple goal of keeping friends when one switched servers but it has grown into something a bit more - content is also preserved as much as possible and you can have a literal clone of your online identity if your primary server dies right now - either for fifteen minutes or forever. Just go to another site and carry on. You still have all your friends and all your content and all your personalised settings. Alternatively you can restore your account from a thumb drive with your last known backup, but most folks prefer the constant sync of their identity rather than losing everything since the last backup. But it's your choice.

Having DNS-independent identity also turned out to be crucial for providing cross domain access control which works after relocation. If you were bob@a.com and moved to bob@b.com and all your friends made content available to bob@a.com, you now have lost access to content which you were already allowed to view - without each of your friends editing every ACL of every resource which included bob and changing it to the new location. If instead they make the content available to your identity (who you are and not where you are), you can access it cross-domain from anywhere your account exists.

win-win.

ghost commented May 22, 2017

Don't really know what you mean by "webby" so can't respond to that.

In the Hubzilla implementation, identity is separate from DNS location. The DNS location is basically "where I am right now" and not "who I am". Content changes and friendship changes are replicated across different channel instances, and site-specific internal links (say photos and attachments in a post, etc.) adjusted accordingly. This started with a very simple goal of keeping friends when one switched servers but it has grown into something a bit more - content is also preserved as much as possible and you can have a literal clone of your online identity if your primary server dies right now - either for fifteen minutes or forever. Just go to another site and carry on. You still have all your friends and all your content and all your personalised settings. Alternatively you can restore your account from a thumb drive with your last known backup, but most folks prefer the constant sync of their identity rather than losing everything since the last backup. But it's your choice.

Having DNS-independent identity also turned out to be crucial for providing cross domain access control which works after relocation. If you were bob@a.com and moved to bob@b.com and all your friends made content available to bob@a.com, you now have lost access to content which you were already allowed to view - without each of your friends editing every ACL of every resource which included bob and changing it to the new location. If instead they make the content available to your identity (who you are and not where you are), you can access it cross-domain from anywhere your account exists.

win-win.

@sandhawke sandhawke referenced this issue May 23, 2017

Open

Forwarding #4

@cwebber

This comment has been minimized.

Show comment
Hide comment
@cwebber

cwebber Jun 1, 2017

Collaborator

No, not really. The content under https://pirati.ca/display/735a2029205920ea17dbae8771484681 you will find under https://squeet.me/display/735a2029205920ea17dbae8771484681, https://friendica.mrpetovan.com/display/735a2029205920ea17dbae8771484681 and under similar urls at some more Friendica servers.

Every message has a guid, in this case it is "735a2029205920ea17dbae8771484681". This identifies the message. Additionally every Friendica message has got an uri. That contains the hostname. But that isn't changed after the relocation.

Thinking about Zooko's Triangle here... how do you deal with preserving uniqueness with guids? It seems like two instances could choose to use the same guid and have a collision. Who wins? If it's a "first come first serve" you could do a kind of attack where you connect to an instance and claim to have all the guids that are actually someone else's, but if the instance you were connecting to didn't know that, you could "take over" those posts as far as that instance is concerned.

Collaborator

cwebber commented Jun 1, 2017

No, not really. The content under https://pirati.ca/display/735a2029205920ea17dbae8771484681 you will find under https://squeet.me/display/735a2029205920ea17dbae8771484681, https://friendica.mrpetovan.com/display/735a2029205920ea17dbae8771484681 and under similar urls at some more Friendica servers.

Every message has a guid, in this case it is "735a2029205920ea17dbae8771484681". This identifies the message. Additionally every Friendica message has got an uri. That contains the hostname. But that isn't changed after the relocation.

Thinking about Zooko's Triangle here... how do you deal with preserving uniqueness with guids? It seems like two instances could choose to use the same guid and have a collision. Who wins? If it's a "first come first serve" you could do a kind of attack where you connect to an instance and claim to have all the guids that are actually someone else's, but if the instance you were connecting to didn't know that, you could "take over" those posts as far as that instance is concerned.

@jaywink

This comment has been minimized.

Show comment
Hide comment
@jaywink

jaywink Jun 1, 2017

If it's a "first come first serve" you could do a kind of attack where you connect to an instance and claim to have all the guids that are actually someone else's, but if the instance you were connecting to didn't know that, you could "take over" those posts as far as that instance is concerned.

You wouldn't be able to "take over" the content. You would only be able to block the content from being delivered to that particular node. Doesn't sound like a very efficient attack since you could only block it from nodes that don't get it delivered in the first place.

Taking over would be only possibly if you get hold of the users private key since you can only own content if you can sign it.

jaywink commented Jun 1, 2017

If it's a "first come first serve" you could do a kind of attack where you connect to an instance and claim to have all the guids that are actually someone else's, but if the instance you were connecting to didn't know that, you could "take over" those posts as far as that instance is concerned.

You wouldn't be able to "take over" the content. You would only be able to block the content from being delivered to that particular node. Doesn't sound like a very efficient attack since you could only block it from nodes that don't get it delivered in the first place.

Taking over would be only possibly if you get hold of the users private key since you can only own content if you can sign it.

@cwebber

This comment has been minimized.

Show comment
Hide comment
@cwebber

cwebber Jun 1, 2017

Collaborator

@jaywink I may be misunderstanding! But let's say that https://pirati.ca/display/735a2029205920ea17dbae8771484681 was the original post, right? Now let's say we have the friendica-compatible https://newbie.example/. Now, that server hasn't federated with pirati.ca yet. But along comes https://malicious.example/ and says "Hey, take a look at this post I made at https://malicious.example/display/735a2029205920ea17dbae8771484681 ! I'm the first one to use this guid, honest!"

Now when newbie.example federates with pirati.ca, and newbie.example first sees https://pirati.ca/display/735a2029205920ea17dbae8771484681 ... so, which post will appear as https://malicious.example/display/735a2029205920ea17dbae8771484681 ? Will it be the pirati.ca one, or the malicious.example one, which is intentionally causing a name collision?

Collaborator

cwebber commented Jun 1, 2017

@jaywink I may be misunderstanding! But let's say that https://pirati.ca/display/735a2029205920ea17dbae8771484681 was the original post, right? Now let's say we have the friendica-compatible https://newbie.example/. Now, that server hasn't federated with pirati.ca yet. But along comes https://malicious.example/ and says "Hey, take a look at this post I made at https://malicious.example/display/735a2029205920ea17dbae8771484681 ! I'm the first one to use this guid, honest!"

Now when newbie.example federates with pirati.ca, and newbie.example first sees https://pirati.ca/display/735a2029205920ea17dbae8771484681 ... so, which post will appear as https://malicious.example/display/735a2029205920ea17dbae8771484681 ? Will it be the pirati.ca one, or the malicious.example one, which is intentionally causing a name collision?

@cwebber

This comment has been minimized.

Show comment
Hide comment
@cwebber

cwebber Jun 1, 2017

Collaborator

This isn't just a matter of "preventing delivery"; you're corrupting the graph by tricking nodes on the network to believe your content is what other servers may be referring to.

It would be different if the big number was a hash and this was a content addressed storage system; that wouldn't be vulnerable to this attack in the same way.

Collaborator

cwebber commented Jun 1, 2017

This isn't just a matter of "preventing delivery"; you're corrupting the graph by tricking nodes on the network to believe your content is what other servers may be referring to.

It would be different if the big number was a hash and this was a content addressed storage system; that wouldn't be vulnerable to this attack in the same way.

@jaywink

This comment has been minimized.

Show comment
Hide comment
@jaywink

jaywink Jun 1, 2017

Will it be the pirati.ca one, or the malicious.example one, which is intentionally causing a name collision?

The first one to deliver that guid to a server would win. There is no way to check the whole network whether a guid has been taken.

IMHO, content ownership in a way that you can verify "I wrote this content" or "I didn't write this" is what matters. "malicious.example" could say "I wrote this with this guid", but it could never say "pirati.ca wrote this with this guid".

There are multiple ways to spam or take down a system. This doesn't seem the most efficient one and would probably quite quickly be recognized by server admins wondering why GUID clashes are filling their logs, after which prompt IP blocks would be implemented against such malicious annoyances.

(also this discussion seems irrelevant as guids are not even used in ActivityPub ;))

jaywink commented Jun 1, 2017

Will it be the pirati.ca one, or the malicious.example one, which is intentionally causing a name collision?

The first one to deliver that guid to a server would win. There is no way to check the whole network whether a guid has been taken.

IMHO, content ownership in a way that you can verify "I wrote this content" or "I didn't write this" is what matters. "malicious.example" could say "I wrote this with this guid", but it could never say "pirati.ca wrote this with this guid".

There are multiple ways to spam or take down a system. This doesn't seem the most efficient one and would probably quite quickly be recognized by server admins wondering why GUID clashes are filling their logs, after which prompt IP blocks would be implemented against such malicious annoyances.

(also this discussion seems irrelevant as guids are not even used in ActivityPub ;))

@cwebber

This comment has been minimized.

Show comment
Hide comment
@cwebber

cwebber Jun 1, 2017

Collaborator

It's not irrelevant because Friendica's guid system was being proposed as a mechanism to solve things, and it doesn't look like it's a panacea here, especially if we're talking about things safely rolling over an actor's content to another place.

Collaborator

cwebber commented Jun 1, 2017

It's not irrelevant because Friendica's guid system was being proposed as a mechanism to solve things, and it doesn't look like it's a panacea here, especially if we're talking about things safely rolling over an actor's content to another place.

@jaywink

This comment has been minimized.

Show comment
Hide comment
@jaywink

jaywink Jun 1, 2017

Friendica's guid system was being proposed as a mechanism to solve things

As discussed on IRC - there are no proposals here that I can see. Just a description of how friendica does things. But discussing options done or possible to do is good 💖

jaywink commented Jun 1, 2017

Friendica's guid system was being proposed as a mechanism to solve things

As discussed on IRC - there are no proposals here that I can see. Just a description of how friendica does things. But discussing options done or possible to do is good 💖

@cwebber

This comment has been minimized.

Show comment
Hide comment
@cwebber

cwebber Jun 1, 2017

Collaborator

I agree that discussing options done or possible is good :)

Edit: And I'm sorry if this appeared to be anti-Friendica, which I think is pretty great software/community. I was expressing my surprise in exploring a detail when exploring whether that was a suitable solution, but maybe it was the wrong venue, I dunno.

Collaborator

cwebber commented Jun 1, 2017

I agree that discussing options done or possible is good :)

Edit: And I'm sorry if this appeared to be anti-Friendica, which I think is pretty great software/community. I was expressing my surprise in exploring a detail when exploring whether that was a suitable solution, but maybe it was the wrong venue, I dunno.

@Gargron

This comment has been minimized.

Show comment
Hide comment
@Gargron

Gargron Jun 1, 2017

Let's say I decide to move from A@X to A@Y. Here's a couple things I think of immediately, that don't involve exporting/importing old content:

  • Old server has all the content - it should probably change attribution?
  • New server might have all or some of the content, attributed to the old account - it should also change attribution to the new one?

There also needs to be verification both on the old as well as the new account. @nightpool has suggested using webfinger redirection on the old end, and webfinger aliases on the new end, i.e. if an account is redirected during look up, and the new response claims the old username@domain as one of its aliases, then we're good to rename the old account in the database (or make a new one and reattribute, not sure on that one)

There's a lot of moving pieces to this, isn't there

Gargron commented Jun 1, 2017

Let's say I decide to move from A@X to A@Y. Here's a couple things I think of immediately, that don't involve exporting/importing old content:

  • Old server has all the content - it should probably change attribution?
  • New server might have all or some of the content, attributed to the old account - it should also change attribution to the new one?

There also needs to be verification both on the old as well as the new account. @nightpool has suggested using webfinger redirection on the old end, and webfinger aliases on the new end, i.e. if an account is redirected during look up, and the new response claims the old username@domain as one of its aliases, then we're good to rename the old account in the database (or make a new one and reattribute, not sure on that one)

There's a lot of moving pieces to this, isn't there

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Jun 1, 2017

There's an RFC on best practises w/r/t message-ids which was developed after we had this problem for years in the email world. They have a "unique" (LHS) component locally and a "@hostname" (RHS) component to avoid collisions in cyberspace. As we discovered with Hubzilla when we adopted this format, you need to make sure everybody you federate with urlencodes these suckers because '@' and '.' are going to cause issues with platforms that don't and use message-ids in URLs.

ghost commented Jun 1, 2017

There's an RFC on best practises w/r/t message-ids which was developed after we had this problem for years in the email world. They have a "unique" (LHS) component locally and a "@hostname" (RHS) component to avoid collisions in cyberspace. As we discovered with Hubzilla when we adopted this format, you need to make sure everybody you federate with urlencodes these suckers because '@' and '.' are going to cause issues with platforms that don't and use message-ids in URLs.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Jun 1, 2017

Old server has all the content - it should probably change attribution?
New server might have all or some of the content, attributed to the old account - it should also change attribution to the new one?

If you separate identity from location, attribution and authorship of content is always made to the identity. Then if location changes, the attribution wouldn't/shouldn't be affected. You would join the identity with the current (or preferred) location and use the result when rendering the content.

There are often local links inside posts which may need to be modified on move/copy. What we've done is search/replace a few of the most important ones (photos, attachments, wiki/webpages, and profile links that belong to you) and then re-sign the content since the old signature won't be valid after content alteration.

ghost commented Jun 1, 2017

Old server has all the content - it should probably change attribution?
New server might have all or some of the content, attributed to the old account - it should also change attribution to the new one?

If you separate identity from location, attribution and authorship of content is always made to the identity. Then if location changes, the attribution wouldn't/shouldn't be affected. You would join the identity with the current (or preferred) location and use the result when rendering the content.

There are often local links inside posts which may need to be modified on move/copy. What we've done is search/replace a few of the most important ones (photos, attachments, wiki/webpages, and profile links that belong to you) and then re-sign the content since the old signature won't be valid after content alteration.

@annando

This comment has been minimized.

Show comment
Hide comment
@annando

annando Jun 2, 2017

@cwebber Friendica uses a special method to create a unique guid: https://github.com/friendica/friendica/blob/develop/boot.php#L799-L816

Means: The first few bytes are the CRC32 hash of the hostname. This is followed by characters that are created with the uniqid function which is based on the current microseconds plus some random stuff. And finally some additional random is added.

A guid collision could only happen when two system had the same CRC32 hash of their hostname (which could theoretically happen - but is really unlikely) and the post would happen at the same microsecond (unlikely) and the random generator would create the same random stuff at two times at the two systems (extremely unlikely).

annando commented Jun 2, 2017

@cwebber Friendica uses a special method to create a unique guid: https://github.com/friendica/friendica/blob/develop/boot.php#L799-L816

Means: The first few bytes are the CRC32 hash of the hostname. This is followed by characters that are created with the uniqid function which is based on the current microseconds plus some random stuff. And finally some additional random is added.

A guid collision could only happen when two system had the same CRC32 hash of their hostname (which could theoretically happen - but is really unlikely) and the post would happen at the same microsecond (unlikely) and the random generator would create the same random stuff at two times at the two systems (extremely unlikely).

@cwebber

This comment has been minimized.

Show comment
Hide comment
@cwebber

cwebber Jun 2, 2017

Collaborator

@annando Thanks for clarifying, that's what I wanted to hear about :)

How do you transfer the "authority" of those old guids from the old user to the new user for updating posts / etc? Or is that basically not worried about, and those old posts are in "archive mode"?

Collaborator

cwebber commented Jun 2, 2017

@annando Thanks for clarifying, that's what I wanted to hear about :)

How do you transfer the "authority" of those old guids from the old user to the new user for updating posts / etc? Or is that basically not worried about, and those old posts are in "archive mode"?

@nightpool

This comment has been minimized.

Show comment
Hide comment
@nightpool

nightpool Jun 2, 2017

nightpool commented Jun 2, 2017

@jaywink

This comment has been minimized.

Show comment
Hide comment
@jaywink

jaywink Jun 2, 2017

@nightpool define "take over"?

jaywink commented Jun 2, 2017

@nightpool define "take over"?

@jaywink

This comment has been minimized.

Show comment
Hide comment
@jaywink

jaywink Jun 2, 2017

@zotlabs interesting, wondered why Hubzilla guid's have the domain at the end.

So I assume on an incoming object arriving, you only accept it if the domain matches the sender, or is the domain part there just to avoid collisions? If it is also verified, this I assume solves the problem that has been raised here, ie reserving a guid on a node that doesn't know about it.

Adding the domain there kind of makes the guid almost an URL. AFAICT the Friendica/Diaspora(future) migration process would be impossible then, except maybe if on transferring owner of content one would also change their guid's to point to the owner new home. I guess that could be feasible to do but would destroy any old links if the guid is used in the url.

jaywink commented Jun 2, 2017

@zotlabs interesting, wondered why Hubzilla guid's have the domain at the end.

So I assume on an incoming object arriving, you only accept it if the domain matches the sender, or is the domain part there just to avoid collisions? If it is also verified, this I assume solves the problem that has been raised here, ie reserving a guid on a node that doesn't know about it.

Adding the domain there kind of makes the guid almost an URL. AFAICT the Friendica/Diaspora(future) migration process would be impossible then, except maybe if on transferring owner of content one would also change their guid's to point to the owner new home. I guess that could be feasible to do but would destroy any old links if the guid is used in the url.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Jun 2, 2017

When cloning or migrating, the message-id isn't altered for the new site. It's a permanent ID. Like email, it's only to avoid unintentional collisions in a decentralised system and isn't checked or analysed. URLs or URIs could also be used. I think this is pretty much required of "feed based" protocols these days and we've had to adjust these in our feeds accordingly by adding an 'X-' scheme.

Just read somewhere that 'X-' schemes were outlawed recently so we'll probably have to do something else and see if we can shoe-horn it into a tag: scheme or something.

ghost commented Jun 2, 2017

When cloning or migrating, the message-id isn't altered for the new site. It's a permanent ID. Like email, it's only to avoid unintentional collisions in a decentralised system and isn't checked or analysed. URLs or URIs could also be used. I think this is pretty much required of "feed based" protocols these days and we've had to adjust these in our feeds accordingly by adding an 'X-' scheme.

Just read somewhere that 'X-' schemes were outlawed recently so we'll probably have to do something else and see if we can shoe-horn it into a tag: scheme or something.

@annando

This comment has been minimized.

Show comment
Hide comment
@annando

annando Jun 3, 2017

@nightpool I guess you misunderstood some things. The guids are created for each post to have some unique identifier across the whole internet. This is nothing that could be exploited for criminal reasons. And even if your only intention would be to block content from some server then you never would know the rest of the guid.

@cwebber The posts are kept at the servers where they existed before. Only the owner is transferred when the "move" message arrived. This message is cryptographically signed, so this should be relatively safe.

BTW: The guids are mostly needed for Diaspora. In Friendica our primary unique identifier is looking like this:
urn:X-dfrn:some.host.name:1:833a21291959312380e48bb342359526

This is the uri that @zotlabs mentioned.

OStatus is using something like this:
tag:host.name,2017-06-03:noticeId=1192216:objectType=comment

annando commented Jun 3, 2017

@nightpool I guess you misunderstood some things. The guids are created for each post to have some unique identifier across the whole internet. This is nothing that could be exploited for criminal reasons. And even if your only intention would be to block content from some server then you never would know the rest of the guid.

@cwebber The posts are kept at the servers where they existed before. Only the owner is transferred when the "move" message arrived. This message is cryptographically signed, so this should be relatively safe.

BTW: The guids are mostly needed for Diaspora. In Friendica our primary unique identifier is looking like this:
urn:X-dfrn:some.host.name:1:833a21291959312380e48bb342359526

This is the uri that @zotlabs mentioned.

OStatus is using something like this:
tag:host.name,2017-06-03:noticeId=1192216:objectType=comment

@nightpool

This comment has been minimized.

Show comment
Hide comment
@nightpool

nightpool Jun 3, 2017

@annando I think you're not being creative enough. Here's an example I came up with in IRC yesterday:

11:58 < nightpool> [15:33:52] That's a little complex, but yeah
11:58 < nightpool> [15:34:04] Say I have a quote-post, like on twitter
11:58 < nightpool> [15:34:32] So I make post B, which quotes post A and says "right on!"
11:58 < nightpool> [15:34:46] That post gets federated to server 1
11:58 < nightpool> [15:35:19] But a clever attacker, who already had seen post A and was 
                   like "wow, I bet a bunch of people are going to agree with this post"
11:58 < nightpool> [15:35:54] Created post A' with the same guid, and spread it around to 
                   all of the servers they knew about
11:58 < nightpool> [15:36:13] so when post B arrives, server 1 is like "oh, I already 
                   know post A, so I don't have to look it up"
11:58 < nightpool> [15:36:37] and displays post B with A' embedded, instead of A.

nightpool commented Jun 3, 2017

@annando I think you're not being creative enough. Here's an example I came up with in IRC yesterday:

11:58 < nightpool> [15:33:52] That's a little complex, but yeah
11:58 < nightpool> [15:34:04] Say I have a quote-post, like on twitter
11:58 < nightpool> [15:34:32] So I make post B, which quotes post A and says "right on!"
11:58 < nightpool> [15:34:46] That post gets federated to server 1
11:58 < nightpool> [15:35:19] But a clever attacker, who already had seen post A and was 
                   like "wow, I bet a bunch of people are going to agree with this post"
11:58 < nightpool> [15:35:54] Created post A' with the same guid, and spread it around to 
                   all of the servers they knew about
11:58 < nightpool> [15:36:13] so when post B arrives, server 1 is like "oh, I already 
                   know post A, so I don't have to look it up"
11:58 < nightpool> [15:36:37] and displays post B with A' embedded, instead of A.
@annando

This comment has been minimized.

Show comment
Hide comment
@annando

annando Jun 3, 2017

@nightpool For Friendica this wouldn't be any problem since Friendica works differently than Diaspora, concerning repeated posts. For Diaspora I delegate the answer to @SuperTux88

annando commented Jun 3, 2017

@nightpool For Friendica this wouldn't be any problem since Friendica works differently than Diaspora, concerning repeated posts. For Diaspora I delegate the answer to @SuperTux88

@SuperTux88

This comment has been minimized.

Show comment
Hide comment
@SuperTux88

SuperTux88 Jun 3, 2017

@annando: @jaywink already asked me yesterday if that could be a problem for diaspora with comments, likes or reshares. And for comments and likes we accept only messages from the correct author (the author of the parent), but for reshares we don't validate the author of the reshared post. But I'll add a validation for that in the upcoming release, so that won't be a problem anymore. But I don't think that that's a big problem, because "famous" post spread pretty fast over the network, so an attacker can't spread a fake post to many servers anymore. And I'm not aware of a case where we had a guid collision like that. But nevertheless we should add a check for that (the protocol already supports it, we only need the check in our implementation).

SuperTux88 commented Jun 3, 2017

@annando: @jaywink already asked me yesterday if that could be a problem for diaspora with comments, likes or reshares. And for comments and likes we accept only messages from the correct author (the author of the parent), but for reshares we don't validate the author of the reshared post. But I'll add a validation for that in the upcoming release, so that won't be a problem anymore. But I don't think that that's a big problem, because "famous" post spread pretty fast over the network, so an attacker can't spread a fake post to many servers anymore. And I'm not aware of a case where we had a guid collision like that. But nevertheless we should add a check for that (the protocol already supports it, we only need the check in our implementation).

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Jun 3, 2017

Message authenticity can really only be verified through application of signatures. Whether or not to include the message-id in the signed data is perhaps an important consideration - as well as how you handle collisions of different author claimants to the same message-id claim, since both signatures could be valid in this case. Most current projects prevent an outright message forgery through message-id, but a clever attacker could perhaps cause a denial of service of an individual message to individual nodes by exploiting the existing duplicate suppression techniques.

I don't recall a signature specification in ActivityPub and the authentication section is only marginally specified - and this will ultimately require rectification. Provenance is lost unless every destination node in the delivery chain validates the message against the claimed author (not necessarily the sender) or validates the entire delivery chain; which is a bit harder.

ghost commented Jun 3, 2017

Message authenticity can really only be verified through application of signatures. Whether or not to include the message-id in the signed data is perhaps an important consideration - as well as how you handle collisions of different author claimants to the same message-id claim, since both signatures could be valid in this case. Most current projects prevent an outright message forgery through message-id, but a clever attacker could perhaps cause a denial of service of an individual message to individual nodes by exploiting the existing duplicate suppression techniques.

I don't recall a signature specification in ActivityPub and the authentication section is only marginally specified - and this will ultimately require rectification. Provenance is lost unless every destination node in the delivery chain validates the message against the claimed author (not necessarily the sender) or validates the entire delivery chain; which is a bit harder.

@Gargron

This comment has been minimized.

Show comment
Hide comment
@Gargron

Gargron Sep 22, 2017

{
  type: 'Move',
  actor: 'uri/to/alice',
  object: 'uri/to/alice',
  target: 'new_uri/to/alice'
}

Sent out to followers.

Old server's webfinger would need to redirect to new server's webfinger, and new server's webfinger would need to list old URI as an alias (so we have consent from both places)

Followers should unfollow old account and follow new one. I believe if we don't build in the unfollowing of the old account, botnets could be created quickly by switching accounts repeatedly. Another thing is that the unfollowing and following would be a lot of traffic. Perhaps servers should rate-limit this operation to space out the follows reasonably.

Gargron commented Sep 22, 2017

{
  type: 'Move',
  actor: 'uri/to/alice',
  object: 'uri/to/alice',
  target: 'new_uri/to/alice'
}

Sent out to followers.

Old server's webfinger would need to redirect to new server's webfinger, and new server's webfinger would need to list old URI as an alias (so we have consent from both places)

Followers should unfollow old account and follow new one. I believe if we don't build in the unfollowing of the old account, botnets could be created quickly by switching accounts repeatedly. Another thing is that the unfollowing and following would be a lot of traffic. Perhaps servers should rate-limit this operation to space out the follows reasonably.

@sandhawke

This comment has been minimized.

Show comment
Hide comment
@sandhawke

sandhawke Sep 22, 2017

Would you also copy over the old posts and comments and likes, or are those ephemera that aren't worth copying and http redirecting?

sandhawke commented Sep 22, 2017

Would you also copy over the old posts and comments and likes, or are those ephemera that aren't worth copying and http redirecting?

@yvolk

This comment has been minimized.

Show comment
Hide comment
@yvolk

yvolk Oct 4, 2017

I filed a bug for #ActivityPub that should allow it to solve a problem of this issue via separation of Actors from Users. With this separation Person's (Actor's) identity is location independent. This is a user Account that binds the Actor to a host/account at that host.
As @zotlabs put it:

...identity is separate from DNS location. The DNS location is basically "where I am right now" and not "who I am".

See w3c/activitypub#260

yvolk commented Oct 4, 2017

I filed a bug for #ActivityPub that should allow it to solve a problem of this issue via separation of Actors from Users. With this separation Person's (Actor's) identity is location independent. This is a user Account that binds the Actor to a host/account at that host.
As @zotlabs put it:

...identity is separate from DNS location. The DNS location is basically "where I am right now" and not "who I am".

See w3c/activitypub#260

@c-johnson

This comment has been minimized.

Show comment
Hide comment
@c-johnson

c-johnson Nov 3, 2017

Hi everyone!

I'm the one who wrote this piece back in April, a long open call for resolution on this issue:

https://hackernoon.com/mastodon-is-dead-in-the-water-888c10e8abb1

Is there any progress being made on deciding / implementing this? I'm ready and willing with a lot of marketing firepower to get the Activitypub/GnuSocial/Mastodon conversation started again the moment a cadre of people come to a resolution on this issue. Just curious what the status / roadblocks are.

c-johnson commented Nov 3, 2017

Hi everyone!

I'm the one who wrote this piece back in April, a long open call for resolution on this issue:

https://hackernoon.com/mastodon-is-dead-in-the-water-888c10e8abb1

Is there any progress being made on deciding / implementing this? I'm ready and willing with a lot of marketing firepower to get the Activitypub/GnuSocial/Mastodon conversation started again the moment a cadre of people come to a resolution on this issue. Just curious what the status / roadblocks are.

@cwebber

This comment has been minimized.

Show comment
Hide comment
@cwebber

cwebber Nov 3, 2017

Collaborator

The topic of follower migration and decentralized identity within federated networks remains a major topic within the SocialCG. If you're willing to wade through the minutes, it was a good portion of our conversation from last week's SocialCG call.

Collaborator

cwebber commented Nov 3, 2017

The topic of follower migration and decentralized identity within federated networks remains a major topic within the SocialCG. If you're willing to wade through the minutes, it was a good portion of our conversation from last week's SocialCG call.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Nov 3, 2017

In the actor record:

"nomadicLocations": {
      "id": "https://server1.com/locs/bob",
      "type": "Collection",
      "totalItems": 2,
       "items": [
            "https://server1.com/bob",
            "https://server2.com/bobcopy"
        ]
}

Bob needs to sign both actor records (on dereferencing the items) with either a common key or with each of his keys. On delivery to "bob", deliver to all linked locations.

Done.

If you want to move rather than copy, a move message is pretty simple. Again, bob would need to sign both the old and new location using either a common key or with all relevant keys.

Both methods have solid implementation experience on the open web. Crafting the actual data isn't rocket science if you just want to express that bob@server1.com is now (or also) bobcopy@server2.com . Changes are really just a Profile update activity. You don't really need a special message type.

There's no reason at all why a project couldn't support both methods, as they have somewhat different use cases.

Changing internal data so it behaves consistently is an implementation issue. It will be easier for some projects than others based on how tightly coupled the original identity is to their internal data and whether or not the data structures were designed around mobility as a requirement.

DID's have also been suggested as a way to solve this problem. I cannot recommend that because the descriptions provided were pretty vague and raised a number of troubling questions; and I haven't personally verified the algorithms to determine if they are sound.

ghost commented Nov 3, 2017

In the actor record:

"nomadicLocations": {
      "id": "https://server1.com/locs/bob",
      "type": "Collection",
      "totalItems": 2,
       "items": [
            "https://server1.com/bob",
            "https://server2.com/bobcopy"
        ]
}

Bob needs to sign both actor records (on dereferencing the items) with either a common key or with each of his keys. On delivery to "bob", deliver to all linked locations.

Done.

If you want to move rather than copy, a move message is pretty simple. Again, bob would need to sign both the old and new location using either a common key or with all relevant keys.

Both methods have solid implementation experience on the open web. Crafting the actual data isn't rocket science if you just want to express that bob@server1.com is now (or also) bobcopy@server2.com . Changes are really just a Profile update activity. You don't really need a special message type.

There's no reason at all why a project couldn't support both methods, as they have somewhat different use cases.

Changing internal data so it behaves consistently is an implementation issue. It will be easier for some projects than others based on how tightly coupled the original identity is to their internal data and whether or not the data structures were designed around mobility as a requirement.

DID's have also been suggested as a way to solve this problem. I cannot recommend that because the descriptions provided were pretty vague and raised a number of troubling questions; and I haven't personally verified the algorithms to determine if they are sound.

@benj-red

This comment has been minimized.

Show comment
Hide comment
@benj-red

benj-red Nov 13, 2017

Follower migration for general reasons is nice. But as a user, I want the feature as a safety net in case something bad happens with my current account/instance.

EXAMPLE A - the instance shuts down
In this case, the solution can't depend on the existence of the instance.

EXAMPLE B - my account gets banned (unfairly, e.g.)
In this case, the solution can't depend on the compliance of the instance administrators. Admins are humans, and as such are vulnerable to Bad Decisions™. Frequently on birdsite, when a marginalized individual gets targeted by a harassment campaign, the harassers will report the individual for an otherwise-innocuous infraction, resulting in a ban for the individual. This is a huge problem -- literally the reason I left birdsite. (I didn't get banned, I was just sick and tired of seeing queer women of color and others get driven off the platform.)

EXAMPLE C - the instance gets toxic
What if in example B the individual didn't get banned, but the administrators neglected to take action over the harassment campaign. At best the admins are M.I.A.; at worst, they could be complicit. In this case, a solution is not reliable if predicated on the admins' cooperation or non-interference.

I don't mean to derail efforts towards a fair-weather follower migration feature. I just please ask for prioritization of emergency migration use cases too. Thank you for the hard work everyone is putting into this. 👏

benj-red commented Nov 13, 2017

Follower migration for general reasons is nice. But as a user, I want the feature as a safety net in case something bad happens with my current account/instance.

EXAMPLE A - the instance shuts down
In this case, the solution can't depend on the existence of the instance.

EXAMPLE B - my account gets banned (unfairly, e.g.)
In this case, the solution can't depend on the compliance of the instance administrators. Admins are humans, and as such are vulnerable to Bad Decisions™. Frequently on birdsite, when a marginalized individual gets targeted by a harassment campaign, the harassers will report the individual for an otherwise-innocuous infraction, resulting in a ban for the individual. This is a huge problem -- literally the reason I left birdsite. (I didn't get banned, I was just sick and tired of seeing queer women of color and others get driven off the platform.)

EXAMPLE C - the instance gets toxic
What if in example B the individual didn't get banned, but the administrators neglected to take action over the harassment campaign. At best the admins are M.I.A.; at worst, they could be complicit. In this case, a solution is not reliable if predicated on the admins' cooperation or non-interference.

I don't mean to derail efforts towards a fair-weather follower migration feature. I just please ask for prioritization of emergency migration use cases too. Thank you for the hard work everyone is putting into this. 👏

@jaywink

This comment has been minimized.

Show comment
Hide comment
@jaywink

jaywink Nov 18, 2017

TBH, account migration as a feature is useful, but what most non-technical users need (who don't spend their time taking weekly exports out of the system or cloning their identity across nodes) is automated backup, and easy restore to another node. Referring to the "instance shuts down" case here, which is unfortunately all too common in the federated social world.

I wrote some ideas about a decentralized backup/restore a few years back that was based on servers collaborating together to store encrypted backup packages of the identity. IMHO maintaining identity and relationships is more important than ensuring all content is backed up. Keeping this scope would allow easily for networks to share encrypted backups without overloading nodes.

If someone is interested the ideas are here: https://the-federation.info/specs/backup-restore/0.1.0.html

disclaimers due to recent confusions

  • this is not a proposal, just a comment that might interest someone
  • this does not trivially solve anything

jaywink commented Nov 18, 2017

TBH, account migration as a feature is useful, but what most non-technical users need (who don't spend their time taking weekly exports out of the system or cloning their identity across nodes) is automated backup, and easy restore to another node. Referring to the "instance shuts down" case here, which is unfortunately all too common in the federated social world.

I wrote some ideas about a decentralized backup/restore a few years back that was based on servers collaborating together to store encrypted backup packages of the identity. IMHO maintaining identity and relationships is more important than ensuring all content is backed up. Keeping this scope would allow easily for networks to share encrypted backups without overloading nodes.

If someone is interested the ideas are here: https://the-federation.info/specs/backup-restore/0.1.0.html

disclaimers due to recent confusions

  • this is not a proposal, just a comment that might interest someone
  • this does not trivially solve anything
@trwnh

This comment has been minimized.

Show comment
Hide comment
@trwnh

trwnh Jul 20, 2018

Is there any particular weakness to, say, adopting a zot-like identity addressing/cloning schema? It seems like it would solve a lot of problems to be able to refer to actors in a domain-independent way, but still have knowledge of their current homes. "Migration" in such a system would be as simple as marking a new node as primary, verifying that this is an authentic request, then notifying all followers' nodes of the change so that they can update their references.

trwnh commented Jul 20, 2018

Is there any particular weakness to, say, adopting a zot-like identity addressing/cloning schema? It seems like it would solve a lot of problems to be able to refer to actors in a domain-independent way, but still have knowledge of their current homes. "Migration" in such a system would be as simple as marking a new node as primary, verifying that this is an authentic request, then notifying all followers' nodes of the change so that they can update their references.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment