When attempting to use the new account export code:
Hello goobgoob/goobgoobgoob
We’ve encountered an issue while processing your personal data for download.
Please try again!Sorry,
The diaspora* email robot!
On pod.orkz.net. What are the most likely reasons for this?
It worked before the update to 0.7; I tested it just a few days ago.
Gnarf, I only tested this on my dev-setup, but not with my account on the production pod … because … it’s my own pod, why should I export my data when I have database backups? 
Anyway, my export fails too and the reason is:
DiasporaFederation::Entity::ValidationError: Failed validation for Photo:036fec7a8488e763 from supertux@nerdpol.ch for properties: property: height, value: nil, rule: numeric, with params: {} | property: width, value: nil, rule: numeric, with params: {}
Old photos don’t have width and height … On my own pod this are photos older than mid 2012 (so newer pods don’t have this problem), I received photos without width and height until mid 2013 from other pods, but they are irrelevant for the export.
Actually I don’t remember, why I made width and height a mandatory property in the federation, because I couldn’t find any validation of them in the old federation code (but only had a quick look). So the solution would be to just make width and height optional in the next version of the gem (if nobody has a reason against it) and upgrade it in 0.7.1.0 and older pods are able to export their data too (older users on older pods, new users on older pods should be fine).
And there is another error (just reported by another user on my pod):
DiasporaFederation::Entity::ValidationError: Failed validation for Reshare:xxx:yyy from zzz@nerdpol.ch for properties: property: root_author, value: nil, rule: not_empty, with params: {}
The problem here is, that the root post is already deleted. But for the federation gem, it makes absolutely sense to validate the root_author, because we should never federate a reshare without this. But I have no idea how to handle that for the export/import?
to_s (Reshare:guid:root_guid) as text and export it as status_message. Then we would need to add special handling for this in the import and filter all Status messages with this text. We could then convert them back to a reshare with deleted root. (This is better than above, but there is still a problem: when we add quoted posts (reshare posts but add my own comment to it), a reshare would already have a text property, so we can’t change this)Since we also have this problem, when somebody wants to fetch a reshare with a deleted root, we should probably do the second thing: remove not_nil validation. We then just need to make sure that a reshare with missing root_author is saved without root (even when there is a matching post with the root_guid, because we can’t validate the author).
@comradesenya what do you think about this?
Thanks for your replies.
@goob I don’t know if your error is one of these or if you have something different, so you can ask your podmin to search “Unexpected error while exporting user” in the logfiles and report the errors?
Done. [insert alternative to 14-character smiley here]
What we may end up doing for federated projects is to generate a link to the original post and replace the reshare body with that link instead of the content if the original post can’t be accessed or validated for whatever reason. This leaves any third party (validated) commentary in place and will let the origination site try and explain what happened (if the origination site still exists; otherwise it’s just a dead link rather than a potentially blank post body).
If anything it would be convenient to see such a backup text/html URL (and perhaps even the entire fetch URL) with the protocol reshare message so we don’t have to calculate them by making assumptions about how these URLs should be constructed.
Yes, that’s currently the case. The reshare stays with the comments when the original post is deleted. Diaspora displays a text then “Original post deleted by author”.
The fetch URLs are specified here: https://diaspora.github.io/diaspora_federation/federation/fetching.html So you don’t need to guess them. But when the original post was deleted, there is nothing to fetch anymore.
There are lots of other failure modes besides the original post being deleted.
Diaspora displays a text then “Original post deleted by author”.
How do other federated projects discover the specific case of deletion? A 404 Not Found can also represent other failure modes. I suppose we can always just say ‘Not Found’ and that’s probably more accurate since we don’t really know why it wasn’t found.
The fetch URLs are specified here:
That represents the new fetch url. Although the majority of sites use the new fetch url, some reshares can only be fetched using the old /p/xxx.xml interface; which we generate as a fallback. My site has fetched old reshares several (6) times in the last two weeks. Why should my project have to maintain knowledge of how to construct URLs to find posts on your site across different versions? If I recall the /p/ link wasn’t ever adequately documented and I had to dig through the code to find it.
If you know the full fetch URL already, why not provide it? And if you know the HTML permalink to the original post, why not provide it? Anyway it’s just a suggestion. Nothing more.
It’s up to you what you display on your site.
You shouldn’t use the old URLs anymore, because they are insecure because it isn’t signed. That’s why they were removed from the code.
The new fetch routes are the only currently supported URLs, so you don’t need to maintain different versions. And in contrast to the old routes the new routes are specified and documented.
Because it’s specified in the protocol, when you have the guid, you can always construct the URL.
Because we don’t know the HTML permalink, it can be diaspora or friendica or hubzilla, and everybody has different URL schemas for the frontend. So I would need to guess to construct a link to the original post. And that’s exactly what you don’t want to do. That’s why there are specified and documented routes to fetch posts via the protocol.
Fixed in 0.7.1.0 