Seed migration feature specification - Review feedback
4 views
Skip to first unread message
Dennis Schubert
Sep 19, 2016, 6:52:58 PM9/19/16
to senya, diaspo...@googlegroups.com
[CC: diaspora-dev]
Hi Senya,
please find my feedback to your specification below. Thank you very much
for your work. It is unclear to me if you intend to use this document
for diaspora only or if you plan on having a general migration
definition for other social networks as well. If it's the latter, this
spec misses a lot of details.
(I added this paragraph after writing everything else). We probably
should clear that first. What do you wanna do here? Initially, we talked
about a migration process that would work for other networks as well.
This document looks like a plan of what diaspora needs to do, which is
not the same. I just read the entire thing and I still don't have an
idea on how this is supposed to work in detail.
Please put the "process description", that is, the needed steps first,
followed by the details. Take a look at the OpenID flow examples [0] for
example.
There is no need to differentiate between "frontend" and "backend" steps
here. Write the directions as unbiased, simple, and neutral as possible.
For example (just wrote that, this is not the actual flow.)
1. User initiates the account migration process by entering the new
servers URL.
2. The old server sends a AccountMoveRequested to the new server.
3. The new server sends a Profile to the old server.
4. After the old server imported the profile, an user archive is created
and a link to the download is provided to the user.
5. The user uploads the archive to the new server.
6. The new server sends a AccountImportCompleted message to the old server.
7. The old server deletes the user account and marks the profile as moved.
And so on.
Here is the original feedback, but I guess we should define our goals
first...
> This document is intended to make Dennis happy
I hope that this was meant to be as a joke. If not, I sincerely am
disappointed that I am the only one seeing the reason for having a very
complex and very risky featured and its underlying principles spec'ed
and discussed.
> and which can talk to each other
Nit: "communicate with each other"
> TODO: Do we want to support "account merging"? [...] Technically it
doesn't differ from the migration to a new account and can be useful.
Are you sure that there is no difference? I imagine merging data created
by two different keys with different signatures being quite edgy.
> Federation entity
Other implementations will not read our source to understand the
resulting XML. Please add the actual XML that has to be send on user
moves or we'll never see anyone else being compatible with our stuff.
> # the old account id
> property :author
I assume this is talking about the "account ID" (or, as we know it, the
diaspora handle)?
> Someone tries to discover a user by the old ID
Please specify that a **permanent** redirect should be used, just to be
sure.
> If that happens, the old home pod must send the AccountRename entity
to the pod from where the message has arrived.
> I would also suggest relaying of the message, received by the old home
pod to the new home pod, but I'm not sure that the additional stability
would worth the possible complexity of the implementation.
If we're able to determinate that the user moved right in the receive
step, we could return an error code and the pod would automatically
retry. But I doubt we'd be able to do this. :/
> New home pod only: create a new user and person in the pod's DB
How does the new pod get the users details like profile information,
email addresses? What about the users password? Should we send a
password recovery email immediately after the account creation?
> Tombstone old person and profile
"Tombstone" is not a verb and even if it would be, it's ambiguous.
Please specify that the origin pod has to remove all user contents and
the profile. Step seems duplicated with step 3. Also, link to GitHub is
not permanent, press the y key on GitHub to make it reload with an URL
that contains the latest revision.
> Update all the DB references
What are "all" references? Where is the person used? How does the old
pod get the new profile after it's created (do we fetch?). After all,
most entities are related to a person which we don't know about after
some federation happened.
> The implementation of this method is postponed to the point after the
manual export is implemented.
Wondering about the timeline. Alice starts the migration from Source to
Target. When does the import happen? When does the migration happen? Is
the archive import a step that can be done after the account is moved?
If so (as specified later in the document), how can "The archive owner's
account is not closed" be a validation argument?
I am totally lost about the actual import stap. In "Backend migration
process" you write that the ID change procedure needs to be done before
importing the archive. However, the archive includes the users details,
which we need to create the new account. I fear we deadlock'ed here.
[0]: http://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth
--
Dennis Schubert
http://schub.io
xmpp:dens...@dsx.cc
Hi Senya,
please find my feedback to your specification below. Thank you very much
for your work. It is unclear to me if you intend to use this document
for diaspora only or if you plan on having a general migration
definition for other social networks as well. If it's the latter, this
spec misses a lot of details.
(I added this paragraph after writing everything else). We probably
should clear that first. What do you wanna do here? Initially, we talked
about a migration process that would work for other networks as well.
This document looks like a plan of what diaspora needs to do, which is
not the same. I just read the entire thing and I still don't have an
idea on how this is supposed to work in detail.
Please put the "process description", that is, the needed steps first,
followed by the details. Take a look at the OpenID flow examples [0] for
example.
There is no need to differentiate between "frontend" and "backend" steps
here. Write the directions as unbiased, simple, and neutral as possible.
For example (just wrote that, this is not the actual flow.)
1. User initiates the account migration process by entering the new
servers URL.
2. The old server sends a AccountMoveRequested to the new server.
3. The new server sends a Profile to the old server.
4. After the old server imported the profile, an user archive is created
and a link to the download is provided to the user.
5. The user uploads the archive to the new server.
6. The new server sends a AccountImportCompleted message to the old server.
7. The old server deletes the user account and marks the profile as moved.
And so on.
Here is the original feedback, but I guess we should define our goals
first...
> This document is intended to make Dennis happy
I hope that this was meant to be as a joke. If not, I sincerely am
disappointed that I am the only one seeing the reason for having a very
complex and very risky featured and its underlying principles spec'ed
and discussed.
> and which can talk to each other
Nit: "communicate with each other"
> TODO: Do we want to support "account merging"? [...] Technically it
doesn't differ from the migration to a new account and can be useful.
Are you sure that there is no difference? I imagine merging data created
by two different keys with different signatures being quite edgy.
> Federation entity
Other implementations will not read our source to understand the
resulting XML. Please add the actual XML that has to be send on user
moves or we'll never see anyone else being compatible with our stuff.
> # the old account id
> property :author
I assume this is talking about the "account ID" (or, as we know it, the
diaspora handle)?
> Someone tries to discover a user by the old ID
Please specify that a **permanent** redirect should be used, just to be
sure.
> If that happens, the old home pod must send the AccountRename entity
to the pod from where the message has arrived.
> I would also suggest relaying of the message, received by the old home
pod to the new home pod, but I'm not sure that the additional stability
would worth the possible complexity of the implementation.
If we're able to determinate that the user moved right in the receive
step, we could return an error code and the pod would automatically
retry. But I doubt we'd be able to do this. :/
> New home pod only: create a new user and person in the pod's DB
How does the new pod get the users details like profile information,
email addresses? What about the users password? Should we send a
password recovery email immediately after the account creation?
> Tombstone old person and profile
"Tombstone" is not a verb and even if it would be, it's ambiguous.
Please specify that the origin pod has to remove all user contents and
the profile. Step seems duplicated with step 3. Also, link to GitHub is
not permanent, press the y key on GitHub to make it reload with an URL
that contains the latest revision.
> Update all the DB references
What are "all" references? Where is the person used? How does the old
pod get the new profile after it's created (do we fetch?). After all,
most entities are related to a person which we don't know about after
some federation happened.
> The implementation of this method is postponed to the point after the
manual export is implemented.
Wondering about the timeline. Alice starts the migration from Source to
Target. When does the import happen? When does the migration happen? Is
the archive import a step that can be done after the account is moved?
If so (as specified later in the document), how can "The archive owner's
account is not closed" be a validation argument?
I am totally lost about the actual import stap. In "Backend migration
process" you write that the ID change procedure needs to be done before
importing the archive. However, the archive includes the users details,
which we need to create the new account. I fear we deadlock'ed here.
[0]: http://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth
--
Dennis Schubert
http://schub.io
xmpp:dens...@dsx.cc
Dennis Schubert
Sep 19, 2016, 7:06:20 PM9/19/16
to diaspo...@googlegroups.com
Reply all
Reply to author
Forward
0 new messages