@tomscott The issue I have with the quick 'n dirty approach is that it could open up a potential security problem. It's not necessarily a technical problem, so much as that it's a problem of social engineering.

If all the process requires is a download/upload of data, what's stopping someone from finding a way to download someone else's data, upload it to a new pod, and pretend to be that person?

@seantilleycommunitymanager in terms of pod-to-pod migrating, could we have the pods actually do the transfer and migration? the user would never actually touch the .ZIP archive (though they could optionally download it), rather the pods would facilitate all of the archive creation, unpacking and loading of data.

@tomscott That's exactly what I was thinking of. There could be an option in Settings to move to a different pod, where you could type in the URL of your Diaspora pod and authenticate with it like it's an app.

This would push your posts, contacts, Aspects, and bio to the new pod, and your old account would simply become a redirect to your current one.

Of course, that's all easier said than done, but from an end user's standpoint, it'd be very easy to migrate by just typing in a URL and clicking a button.

I think this is a key feature for Diaspora, as a decentralized network.
Speaking about a quick approach, the possibility of abuse that Sean Tilley voiced - how possible is it?

really glad to hear this is not being abandoned, I think its a really important feature. As far as downloading a zip of your data goes, I think that's fine for people to have a copy of their stuff, but not as a way of transferring data between pods.

@seantilleycommunitymanager it may be difficult, but i believe this is the first step to providing 3rd-party applications access to DIASPORA as well as providing us with a much-requested feature. we can use the pod-to-pod authentication and transmission knowledge we gain here to build future things that deal with 3rd-party apps.

but that's all out of the scope of this proposal. i'll write up a decision and let's get to work.

@louigiverona depends on how we make it. we can't just let someone POST to /users and have us set up a secure keypair and password for them. Since we're not running a centralized network, it would be possible for me to take Sean's data and upload it to a different pod, and therefore pretend to be him on DIASPORA. Although [email protected] and [email protected] would be slightly different, it would be difficult for the common person to distinguish and may lead to some clever social engineering/phishing scams. We don't want to facilitate that in any way, so we need to make sure this whole thing is done securely.

Export of data is only of use if you can import it to your new pod. Otherwise you may as well just close one account and open a new one.

@jonneha, @goob and @mataloutreach -- lol i think i got the idea of "decisions" here incorrect. i should have put the whole proposal up there.

But before I do, does anyone know if we can write files to the HD on Heroku? If not, we need to make this an optional feature so Heroku pods don't crash when this happens.

We already can export some data? Why would that not be needed - even Facebook allows you to do that :)

All we need is an import. I don't see the security problem since you're not supposed to give your data archive to anyone else. Own fault if you upload it to the internet and someone uploads your data on another pod.

The security concern is that we need a way for another pod to authenticate as the existing user, otherwise one could simply pretend to be someone else to the network. We just need the private key of the user on the new pod and generate and establish a new keypair on/from the new pod, so that the old pod can make no further posts in the name of the user.

I say let's just do a simple upload for now and reuse the actual data processing logic there when the automatic wizard thingy is done. This way there is no risk - any more than there is now. I could create [email protected] and pretend to be him at any time :)

For data processing for example contacts in aspects would be nice to be auto-created - imho this could be first step.

The other small concern of mine is facilitating full data export: that is to say, if a user is on a big pod like JoinDiaspora.com, and has two years worth of posts, photos, and a couple hundred contacts, exporting all of that could be considered database-intensive, especially if lots of people try to do a full export on the same day.

Would setting a variable that defines how much time a user must wait to perform the download after requesting all of their data be a good idea, so that the database doesn't get too strained if everyone tried to download all of their data all at the same time?

Facebook does it nicely by putting it in a queue and then emailing the user later when the archive is ready.

@jonneha about authentication on the new pod, one more time, Persona can be the solution there, because the user will be able to log in on every website, so we can simply ask the user to log in. We really need to use Persona for authentication. Will take a look at that in February.

@flaburgan I was talking about server to server authentication, not client to server.

Hm, if the new pod is able to know that the user who wants to import data is the one who is connect on the old pod, the problem is solved, isn't it ?

How do you prove to the other pods?

Jonne, I'm not sure we need such rigorous authentication if we're talking about a two-step process, as follows:

1. User exports their entire account data to a local file on their machine.
2. User creates account on new pod and imports account data file to new account.

Only the authenticated user of the original account will be able to export the data from that account, and if they're downloading it to their local machine before uploading it to the new pod, unless they do something stupid, the file won't get into third-party hands.

If we're talking about direct transfer of account data from one pod to another pod, then yes, secure keys will be needed.

@flaburgan i looked into it, and while Persona would be our choice for SSO i don't think it's what we need here. i'm not going to rip out our entire authentication system so we can add one little feature.

@jonneha an alternative idea to this is tokens. say a user downloads their data from podA and wants to migrate to podB. we could embed a token inside the archive in a JSON somewhere, then before an upload happens on podB, the server checks the token (like a checksum) against podA's /user/:id/token endpoint and makes sure they match. if they don't, that archive didn't come from podA and it's an impostor. this allows podB to "make sure" the user in question is actually coming from podA. it proves identity, and IMHO building a system where identity doesn't matter is just opening the floodgates for spam and other social engineering.

i don't think most people are observant enough to notice [email protected] is not the same as [email protected]. Especially with the exact same profile, exact same pic, exact same status updates. It would be less obvious if it was something like [email protected] vs. [email protected]...

@goob again, there's no way to prove that said User is in fact the User from their originating pod. I personally think identity matters, and identity isn't just your login@pod_host.com...

My aim would be a seamless migration, lets say we have bob@podA who friendes alice@podB and wants to move to bob@podC. I'd like to have the contact for bob and alice on podB change without any action from alice. This could be done by sending a "I'm here now!"-kind of message from podC to podB. The only way for podC to prove that he now owns bob@podA is signing that message with bobs existing private key, podB already has bob@podA's public key and can thus verify it and update all records.

@tomscott I think you're missing the point of what I said.

There is currently nothing to stop me from opening an account on a pod under the name Tom Scott, and pretending to be you. However, what I won't be able to do under the scheme I outlined is to import your account data from your existing account to the new fake account I have set up, because I won't have access to the account data. Only you (and, perhaps, your podmin) have access to those data, so only you will be able to create a new account and import the data from your existing account. I suppose a simple key could be added to the data export, which the new pod could then check with the old pod to confirm that this is a genuine export from the old pod.

@jonneha if you think a seamless transfer is feasible, that would be far preferable. It may prove to be the easier way of transferring all the connections with other accounts. The only thing I'd add to what you said is that from a privacy point of view it might be wise to notify Alice (and others) that

'Your contact Bob has moved his account to podC. Click here to confirm that you are happy to continue sharing with him at this new pod, or click here if you wish to stop sharing with Bob'.

Reason being that Alice might feel she can't trust the podmin of podC and doesn't want anything to do with it, nor for any of her postings to be potentially available to that podmin through her sharing with Bob. There may be no logical reason for her to feel this way, but Diaspora seems to be all about being up-front with exactly what's happening with your data, so it would, I think, be good to notify a person's contacts when that person moves pods, just to make people aware of what is happening and allow them to make the choice of whether to continue sharing.

I suppose, when someone starts the process of migrating to another pod, a pop-up could be shown them to notify all their contacts 'Hi, just to let you know I'm moving to podC. This won't affect our contact and you don't need to do anything' so that Bob's contacts know in advance.

@goob i see what you're saying. i think we're on the same page. :)

what do you guys think is easier though, a seamless transfer from pod->pod where we have to test and code every step of the process, or allowing humans to do the downloading and uploading of data, as long as the server(s) maintain the authorization process. i'm thinking the latter would be much easier to implement and just as secure as if we had pods take care of the "whole shebang"

I think the seamless transfer Jonne is talking about is best as an ultimate aim, but suspect there is a lot of coding and checking to do on the way to that. I think a two-step manual export/import could work well as a stop-gap measure, allowing those who really want to do so to migrate pods sooner than later. (I'd like to, as I want to set up my own pod, and this is one of the things which is stopping me.)

If the manual two-step process, perhaps with an authentification key as part of the export package, is easy to implement and can be done soon, I'd say let's implement that as an interim measure, and work on the seamless migration in the longer term.

My use of the word seamless was entirely scoped to setting up/maintaining existing relationships. IMO a migration is a transfer, a move, not a duplication of a account and leaving the old one abandoned. As I basically outlined in my over a year old but still standing proposal. The way the archive is transferred is more of a implementation detail, it could be download/upload, POST to special route of old pod, generating a URL and leaving it on the old pod, entering the URL on the new pod, all of the above, whatever else. One benefit of my approach (given the archive is downloadable) is that it could serve as a backup, since the deletion of the old account is tried but not required for the process to complete and thus there's no point where the old pod needs to be still reachable.

The data exporting is needed regardless of whether we allow it to be uploaded :) But of course we already have that. Just saying.

Jonne, with the two-step download/upload method, there could be a step built in to the activation process of the new account at which, having had chance to check that everything has uploaded properly and is working as it should, the user is prompted to click a button to fully activate the new account (ie it was in a testing mode before that). At this point, the key is sent back to the old pod to instigate closing the old account, if the user hasn't already done that. This should solve the problem of duplicate account lingering all over the place. I hope.

Jason, at the moment you can only export a very limited range of your account data. At least, that was still true the last time I tried it.

@jasonrobinson is right about the account export options. we got photos and the profile, not sure if we have posts yet but it doesn't matter.

i say since that's already shipped we work off that, and if we choose to we can expand the export option(s) in the future. but i think that's enough data down there to experiment with building a pod->pod migration option.

@jonneha one issue with your data export model is, wouldn't we need to eventually write the archive to the local disk, and then POST it to an endpoint somewhere else? If so, I have a number of questions about how we're gonna do it:

1. A lot of web servers aren't configured to handle uploads of such a large size (given a reasonable amount of photos these archives could get rather large quickly). Would POSTing somewhere around 50mb of data to an endpoint on a pod require any sort of custom server configuration?
2. How would Heroku users handle this upgrade? Heroku can't write files to the disk, so how would we export to Heroku pods?

IMO it seems that making users manually manage the upload/download process would be a lot easier and still retain the level of security we need. API calls that check a token for validity would be all we need to make sure the "right" user is trying to establish the "right" account on a different pod.

I could imagine a solution using STUN to puch a connection through any possible firewall or NAT and the servers involved connecting directly and exchanging as much data as they want over random ports they negotiate over the normal HTTPS protocol.
(A little like FTP, with a control connection and a separate data link)

Of course ... that's a LOT of work

Didn't we already agree to do this, Tom?

But, as discussed before, an important step in the import process should be, once the user is happy that the import has taken place correctly, the new pod communicating with the old pod and providing it with a key generated by the old pod during the export process, which then prompts the old pod to delete the old account. This will mean it is a proper migration (leaving the old pod and moving to the new pod) rather than simply opening a duplicate account.

The new pod will also need to communicate with all pods with which the account is connected to tell those pods where the account is now located, so that contacts will not lost touch with the account.

@goob it will be the user's responsibility for now to clean up their old account. we'll provide a message stating that but for now, it would just be much easier

and for the record, no, this decision was not made before. As you can see below, "Export pod data to an archive" was already decided upon, but I closed it early after Jay pointed me to the code that was already in master dealing with export archives.

Uh, that was a rather short running time...

@jonneha all of the decisions have been 3 days i think. should i make them for longer in the future?

Maybe in this thread, but I usually try to include 2 weekends.

I think this topic is being over complicated. Realistically, due to the distributed nature of diaspora there could be duplicate contact public names on different pods. The issue should be how to safely transfer from one Pod to another without losing touch with friends on the current and other Pods.

I have drafted simple proposal for transfer authorization. Please tell me your thoughts.

https://docs.google.com/file/d/0B9CMUJ5UVuEkSlRUUU1mNjhGU1k/edit?usp=sharing

Thanks for your work.

This is pretty much what I outlined, except for the additional email step. My proposal has the advantage that PodA could be (permanently) down when the transfer happens. And I'm missing a form of authentication against third parties in your proposal. How would you ensure that a rogue pod doesn't simply announce that a user now lives at him (given he somehow managed to know a few contacts of the user)?

It is the job of PodA to announce to the contacts that the user has moved. PodB has no part of that process. The optional contact list I mentioned as part of the archive is just that, a list. It bears no ability to set up communication with the other pods unless manually executed. Whereas, the PodA contact update is automatic which friends' pods will autoupdate to the new pod without interaction.

@samgleske That's an awesome proposal, and I agree with the way it plans to carry out the ultimate goal of having fully-transferred, unobtrusive migrations from pod to pod in our own network.

Awesome @samgleske - good step forward having something written down in a document.

That is definitely a good step in the right direction.
We just really need to focus on the authenticity of the data we let someone import. By which I mean I want to avoid people creating accounts and then spamming a server with fake imported user archives, thus opening a door for DoS. Also, I am not convinced our asynchronous protocol is set up to handle the handshake and communication necessary to establish what is outlined in step 3.

Also, I would at least inform the contacts of a user that has changed Pods about it, maybe even let them confirm it first. e.g. "Your contact 'name' has moved from 'podA' to 'podB'. Please confirm."
Another possibility would be to display a move in the stream as a "special status update" for all of the users contacts.

Waiting for someone having the time to develop the whole solution, a temporary solution could be allowing to export and import a list of contacts. This would be only an handles list so no problem about identity or anything.

I've made a half-ready script that uses cliaspora and the existing export functionality. Due to way things work unfortunately cliaspora is not able to trigger a search for users not known for a pod, so it only works for users known to the pod where moving. Need to clean up the code also and somehow make it work, either by patching cliaspora or triggering a search outside it.

Fantastic, Jason. More power to your coding elbow.

Should we create a working group to investigate and decide on the best approach to solving the account migration issue? It's such a key issue to Diaspora's success that I wouldn't want it to fall on to the back-burner.

I think we have to put energy here, as joindiaspora / diasp.org become really too big. Allow users to move from a pod to another can solve a part of this problem.

Yeah, this is a huge priority. Bigger pods have to deal with more workers, and therefore more potential hiccups. If we can facilitate a way to easily and securely migrate to another pod, we could potentially address some of these network issues with federation, while also encouraging smaller pods to pop up.

As pointed there, I think we should at least provide a way to export and then import contacts (and with them, Aspects). I don't see any downside with a simple json containing that, so we really should do it soon.

How labour-intensive would it be to code a simple manual migration process for now:

1. User exports their entire account data to a local file on their machine.
2. User creates account on new pod and imports account data file to new account.
3. Contacts are then informed that this person has moved from pod X to pod Y, and are asked to authorise connection to new account on new pod.
4. User is prompted to close their old account manually.

Just to get the possibility of moving one's account, even if it's not the tidiest method of doing it, as quickly as possible, while the exact method of creating a seamless transfer of the type Jonne proposes which is also secure is debated.

If an interim method isn't going to be prohibitive in terms of coding effort, I could start a proposal on this, but I don't want to do so before hearing from devs on feasibility.

@goob I was thinking about that but without a special information for the contacts. They would just receive the classic "bob started sharing with you" when contacts will be imported in the new account, I think this is enough.

I thought a good idea to create an interim proposal in the hope of moving things forward.

Would it be worth doing a call-out from the Diaspora HQ account for people to form a working group to work on this issue? It is a key one and likely to be quite labour-intensive. If so, what should the notice say? I can post it once we've decided.

Importing posts is a bit tricky as they would all have to be new instances of the post. Don't really see what the benefit of this would be since all interactions with the posts would be left behind.

I'm not convinced a temporary export/import will solve the "problem", but it would at least be a start.
We need a working export function anyway...

Diaspora* claims that you own your data - but we don't have a working export like many other services, Facebook for example ;) I'd consider this a high prio.

I don't think it's a long-term answer, @florianstaudacher , but it would provide at least a rough-and-ready means for people who are really keen to move pods to do so. And as it's been one of the cornerstones of the Diaspora philosophy and marketing from the beginning that you can move pods, I think it would be good to have at least some means of doing so as soon as possible.

I'd suggest also including profile information as well as contacts/aspects/followed tags.

@goob profile information could be personal data, I think we should not include that while we don't have a secure process.

Fla, I don't see it that way: we're entrusting the user who is migrating their account with the security of that account data between export (which can only be done by the person with the account password, so is secure) and import to a new pod.

This includes contact information, which are other people's private data, so if we can entrust the migrating user with those data, we must be able to entrust them with their own profile information.

if they are silly and lose/give away the export before uploading it to a new pod, that's their own fault, isn't it?

@flaburgan - why should a user not be able to import profile data from an archive? It's just text after all - they can set it by hand to whatever they want anyway.

The security issue comes from migrating posts which is the content that has interactions with other users and those interactions cannot be remapped easily. But profile data is just personal data that the user should be able to take with them and import.

Also we really should allow users to export their own post (without interactions, like comments and likes by other people). Just for archiving, not uploading. We advertise that users own their own data. Even facebook and google services allow export of data :)

I'd like to point out how integral this feature is once again. Yesterday on a post of Sean's the discussion got crazy essentially over the fact it's way to hard to pick up and move to a pod. https://joindiaspora.com/posts/2773187 we definitely need to commit time to working on this.

Do you think it would be good to advertise on D itself for developers to form a working group to help create this? I can post from the DHQ account if someone who has technical knowledge will help me draft a post.

I think for this and the other key but major things, it's a good idea to set up dedicated working groups who will work on the task. There's a proposal at the moment to do this for federation, for example.

Dennis, I agree that 'quick and dirty' solutions aren't always ideal, however they can sometimes be better than no solution, which is what we have at the moment regarding account migration.

And this manual solution need not be 'quick and dirty' in coding terms, but might well be an easier thing to code than a fully automated process such as Jonne proposed earlier in the discussion, and therefore could be developed and implemented more quickly.

Just to provide reference for anyone that missed it, information and code for the migration script @jasonrobinson has been working on can be learned about in this post: https://joindiaspora.com/posts/2814800

Aiming to get a new version out soon that uses the latest diaspy and also does tags. But this is just a little hack helper thingy, we need proper export and after that a little-by-little import functionality (contacts at least first, like this script does them but internally).

@jasonrobinson Hey, what's the progress on this?

@seantilleycommunit just haven't had time :( Hopefully I'll get it done asap, so user doesn't need to know anything except run some commands in the terminal.

@jasonrobinson has there been any progress on your script, and do you think it's something on the base of which a migration feature might be able to be worked into the Diaspora codebase in the future?

@goob sorry haven't touched it since I've involved myself in way too many things and since I myself don't need a pod migration script any more, I've not needed to touch it yet. I plan to at least package it properly and then that will be it.

This script is just a hack and not usable for permanent code. The proper way should be to allow the user to 1) export contacts as CSV and 2) import them on the other pod - that would do exactly the same thing.

No problem, and no need to apologise. I just came to this discussion to bump it, and saw the end of it, I thought I'd ask where you'd got to.

Anyone got any suggestions about how we can get this moving? What would people need in order to create such a facility? And how can we enthuse people to work on this? We have agreement that creating a manual export/import as an interim measure is desirable, but what steps do we need to take now to try to get things moving.

Wish I could help with code!

A manual export is not an interim solution - we need that anyway, so would be a good place to start. I guess we need some blueprint on the data export format, contents, etc.

@jasonrobinson how would you suggest we proceed to get this blueprint and so on?

@goob someone needs to write something up and propose I guess :P On my todo but I don't think I'll be having time to tackle that any time soon :(

Maybe a good idea would be not to try and cover everything at once - instead just some basics like contacts which imho is the most important thing to start with.

You suggest exporting in CSV. The old system was XML.

Does anyone else have suggestions for the best format to use for export? As suggested by Jason, we'll take a vote just on contacts export first, but it might be necessary to take into account other things that will be exported in the future (posts, photos, etc) in deciding which format will be best.

In fact, the 'old' exporting in XML still works - I just tried it. I thought it had been broken at some point. Is there any reason we can't retain this export as it is, and look to build an import for at least some of the contents?

What about exporting everything as JSON?

I agree with @jasonrobinson; exporting and re-importing contacts is the only feature I need to migrate to another pod and definitely abandon joindiaspora. Jason, I tried your hack script but it fails at login on source pod, returns 406.
No preference on format since I don't develop on this project t--I'd just say, on the projects I work on, whenever I can I dump XML for other lightweight solutions - csv mostly.

@goob I'm pretty sure I meant to write JSON :)

I'm not sure we really need to vote whether we want to export contacts? Surely we do not want to be worse than Facebook - which allows you to export just about all the content you post ;)

But of course if someone wants a vote we can vote. Still, someone needs to write some code for it, I think that is the real reason the export still sucks - not that we don't need or want it.

I agree we don't need a vote on whether or not to create an export facility - it's essential, and in any case the vote has already been taken - I meant that we should vote on which format to use for export. My previous comment wasn't very clear about that.

Worth taking a vote on using JSON as the export format?

@goob yeah sure, we can do that, then make a blueprint for the actual contents in the wiki

@goob about the old export btw - it doesn't really work. It exports a huge amount of stuff that a lot of is totally irrelevant to a user. Did you look at it? :) Also the XML doesn't necessarily even come out valid - bug https://github.com/diaspora/diaspora/issues/4032

@jasonrobinson I've not looked at it in detail, just saw that it contains contact information, post information and one or two other things (I think, can't remember now). When I said 'it works', I simply meant that the export button does still provide you with a dump - not necessarily that it was in any form which would be useful for importation elsewhere.

@rich1, now you're in the swing with JSON, how about creating an export feature...? ;)

I could write one in .NET - not sure it'd be of much use to anyone though?? Unless it's externally hosted perhaps... Hmm... I'll have a think about that :)

@rich1 well it needs to be part of the d* core code - but if you have good ideas on the structure, feel free to create some specs on the content ;)

//offtopic
Hey, new version of diaspora-tools out, Python script to migrate contacts across pods - a little more reliable now, uses fresh diaspy and also works out of the box with SNI SSL pods with Python 2.x (like my pod :P).

https://github.com/jaywink/diaspora-tools
offtopic//

As written down in my explaination: I'd go for JSON as it comes to contacts/aspects, since those are simply data.

On the other hand, posts are embedded in context, which XML can better map, I think.

When it is zipped anyway, why not split those information?

Hey! :-) What's going on with the "import" feature?

Is it developing?
Cheers!

This is a really old topic and we discussed a lot to find out how to implement this feature but codewise nothing happened. I'd suggest that we divide the feature in some smaller steps so we can see some progress with less effort. The first step could be:

Implement manual import/export from the settings page including the following user data:
name, 5 profile tags, bio, location, gender, birthday, nsfw profile, searchable profile, language, show community spotlight in stream, email notifications

We will need two buttons: one to export the data (as json?) and another one to upload a file and overwrite the existing settings with the ones given in that file. Later we could let the user decide which profile information he/she would like to export/import.

The implementation should be easy and even could be doable for a newcomer (as long as he knows some RoR).

What do you think about this? Is it a good idea to divide the feature into smaller ones like I proposed or am I missing something?

Absolutely - small steps as all other things. Maybe we could make a master task with subtasks - that approach seems to have worked well with the UI rewrites?

@ruxton I think you we're working on some parts of this - any progress?

I agree with @steffenvanbergerem .

The next step is enabling re-import of the existing .xml-profile-exports.

@mrfrety I am not sure if we really want that. Even the export we have right now looks broken to me and adding support for the existing xml files adds extra complexity. As a first step I'd prefer export and import of basic profile information. The next steps would be adding more information to the import/export feature and drop the old xml export as soon as we are able to export (and import?) all personal data.

I think there is just a small number of users who already closed there accounts and really need to import their old xml files. For those we could create a tool (separated from the diaspora* codebase) which converts the old xml file.

I made a new "meta issue" to track this whole thing with different smaller tasks - https://github.com/diaspora/diaspora/issues/5343

Plz feel free to work on any of these :)

Posted my proposal regarding account backup and restore, ie migration. Comments welcome.

Nothing much happened in the Jasons post https://github.com/diaspora/diaspora/issues/5343 . I and many other community members want this feature desperately and we all remember that backing up and shifting house to another pod was promised by diaspora* long back.

Im commenting here by assuming that with personal data import/export, we also mean pod migration.

This, is a critical issue for a decentralized network:

Biggest issue with there being no pod migration is that if the pod i
am in goes bust, my account, connections, everything go bust.

that practically kills all the purpose of decentralization.

as long as i am locked into one pod, i am on a centralized network.
content spreading in a decentralized fashion does not make up for it.

as appalling as it is, i can trust that my account on facebook will be
there for a loooong time. even if they use my data as a means to
profit off of me by selling it to government and advertisers, that
also ensures continuity of my account.

but with diaspora, i am obliged to trust the effort of a small group
of people or even one person setting up a server somewhere and then
being able to maintain it through the years. which can go bust at any
time due to a million reasons.

if, somehow, an established organization with endurance sets the
server up (ie a corporation, a ngo etc) i have to be wary of their
motives. yeah that's a great diaspora server with tens of thousands of
users, but it can even be a front by an intelligence organization to
spy on their users - they do it with tor.

or i can set up my own server, and have to deal with everything that
comes with setting up and maintaining a server. which, many of
diaspora users cannot do.

or i can use the apparently not so mature p2p client and battle with
many issues.

@unity100 that's why this is one of the highest priorities for the project, and why community members contributed €4750 towards the development of this important feature. You can follow the current progress of development via the #senyadiasporaaccountmigration tag.

thats great to hear, goob. i already have a wide social circle on diaspora, but the fact that i wouldnt be able to move my account if something happened was considerably discouraging me from using it as my main social service.

i look forward to this feature.

It is taking a long time to complete it properly, because it is a very complex mechanism to produce a migration feature which is both secure and easy to use, but it is absolutely one of the highest priorities for development.