For a first install, there is nothing for a podmin to be warned about. For a second install, well, they have read the instructions before, so they also read the large red warning. If someone decided not to read the backup section on a new install, then clearly they do not care about data loss, so they’d also not read any other warnings we put up. 
If we’d put all “important information” at the top, nobody would ever read the installation guide, because it would be prefixed by 20 warnings and red boxes.
No. There is one GUID assigned to one profile. The GUID of your profile is generated by your pod and federated alongside the rest of your profile. A profile always has one and only one GUID. In your case, there are “different GUIDs on different pods”, because you generated a new profile multiple times, but that doesn’t change the fact that these are technically different profiles that just happen to share the same diaspora* ID, which is where the breakage originated. One diaspora* ID belongs to one GUID, and if that rule is broken, something went horribly wrong.
so the old contacts would not share with her, would not pull content from her and generally would not consider her to be the same person.
GUIDs are a) public, b) not used for the account identification or discovery. Because of a), spoofing the GUID would be simple, and b) is a given, because a GUID alone is worthless in a federated syste,. If you don’t already know the profile, the GUID does not allow you to look up the profile, as the GUID contains no information about the username or the pod. The GUID is just a simpler internal identification mechanism, which we could simply remove and use the diaspora ID everywhere (there are reasons why we do not do that, but that’s not the point of this discussion).
GUIDs are not an authoritative account identifier, only the diaspora* ID is.
It is an adminstrative decision, as far as I see, not a technical one; I am (actually, I was) interested in both. […] This is your personal preference and attitude towards problems
No, it is a technical decision, because as we have explained multiple times, there is no way to alter/refresh information without a profile’s private key. Just manually dropping entities from the database will break relations to other tables, and things will break in hilarious ways because of that. There is a reason we ask people not to mess with their database, and there is also a reason why we design interfaces and protocols the way we do.
I do have backups of the database stored in multiple locations, and I have no intentions of dropping the database because I want to reinstall my pod. Besides, your point is even funnier if you consider the actual past of the pod. Because in the beginning, we actually did drop our database twice. Once on purpose, where we changed the domain from gerspora.de to geraspora.de, and again shortly afterwards, after some heavy reconstruction work on diaspora* corrupted some profiles, where I had to face the reality that 9 account handles were effectively burnt (just like yours) because they missed the deadline of a previous backup. I created dummy accounts with all the previously used usernames and permanently blocked them, to ensure that these identities will not get used ever again, because I couldn’t guarantee that communication with those handles would work, and I also could not retract previously federated profiles. Not sure where you’re going with that point, but you kinda failed.
I would try to help my users, in that alternative universe, to the extent of possible safety within the security’s limits. And maybe get burnt, who knows?
Saying “you can’t do that” is * precisely* helping you to the extent of what we can do. Even though it would be simple to come up with a few lines of ruby script that would re-fetch your new key and override the old one, that would not be an honest solution, because you can’t fulfill the requirements needed to make that solution reliable, namely:
- Knowing which pods have a copy of your profile. This point is straight up impossible because your pod does not keep track of the pods that have queried a copy of your profile, and you can’t even “brute-force check all pods” because there is no complete list of pods.
- Getting all those podmins to run that script, which you also will not achieve, given I am already one blocker, and I know at least 2 more podmins of big pods who will not manually re-fetch keys.
Without fulfilling both requirements, you end up in a state where communicating with some pods works and breaks with other pods, and in a couple of months, nobody will know why that breakage is a thing. And even if you remember what’s up, your users won’t. And from their perspective, all they see is an unreliable communication system where you can’t actually be sure that stuff ever works.
We care about building systems that work, and we try to guarantee that to the best of our ability. Providing workarounds that violate the core design of our system, as you ask us to do, is a direct violation of that, so it’s just not going to happen.
One last time, and then I’ll stop to avoid us spinning in endless circles: If you open a Swiss numbered bank account and you somehow end up losing the identification papers, well, congratulations, you lost the money. No matter what fancy passports you bring up, or how loud you yell at the teller, you won’t be getting your money back. diaspora* is a cryptographic system that depends on asymmetric cryptography for encryption and verification. If you end up losing the matching private key, you won’t be getting that identity back, no matter if you can prove domain ownership, and no matter how loud you yell at the project. It’s just not going to happen.
