In the stock Lemmy web client there is apparently no mechanism for users to fetch their history of posts. The settings page gives only a way to download settings. This contrasts with Mastodon where users can grab an archive of everything they have posted which is still stored on the server.
Or am I missing something?
IIUC, there is no GDPR issue here because no data is personal (because all Lemmy accounts are anonymous). But if a Lemmy server were to hypothetically require users to identify themselves with first+last name, then the admin would have a substantial manual burden to comply with GDPR Art.20 requests. Correct?
Woah… that question triggered a lot of homework for me and I still can’t concretely answer it. From a GDPR standpoint, I’m not sure. The Working Party 29 covers data portability in doc wp242. This bit touches on it:
There are requirements that the procedure be easy for data subjects. It’s worth considering the main motivation for Article 20: to facilitate competition ultimately to give consumers choice. It was written with services like Twitter and Facebook in mind, whereby a corporate commercial service wants to make it as difficult as possible to switch to a competitor.
So you can imagine that the mere existence of an API may not satisfy the requirement that a full download be easy if the API is designed to impose much logic in the consumer code. OTOH, the WP29 opinion only mentions ease for the data subject, not necessarily ease for the new data controller. So if the current data controller makes an API available but makes getting a full data set a complex task of searching for content and grabbing one record at a time, I’m not sure how that would play out in a court.
I actually think the wp242 falls short because it’s only 15 pages and leaves a lot of questions. What if a data controller offers an API, but the API includes a CAPTCHA that the new controller must solve? The new controller would have to implement code to redirect the CAPTCHA to the data subject, which the old controller could make very painful to thwart data subjects exercising their Art.20 rights.
Guess I would have to dig into case law to know more.
GDPR aside, from a practical standpoint, if the API were enough then why have clients? The API is only ½ the solution, which needs a client. If there are no clients to fetch the data, then users are not getting their data. Alternatively a Lemmy server fetching data from another in a migration would not call for a client app, but that’s not happening either.
Mastodon’s web UI includes an archive fetch feature that give users a tarball. That feature is not in the API; it’s unique to the web UI. Kensanada wrote a client to grab user’s data using the API (which has no archive interface, just an interface to search and grab one record at a time). So the mastodon API is a bit haphazard and excludes the simple tarball fetch that the web UI has. He had to write the code to detect if the same record was fetched 3 times, it then concluded that all the data has probably been fetched after a certain amount of repetition occurs. I think users can configure how many duplicates might imply that all data was grabbed, but it’s a bit shitty that the API creates that situation of uncertainty. You don’t really know if you have received all the data from the Mastodon API. It’s an example of the existence of an API falling short of expectations.
OMG didn’t know there was all that law around API’s. Anyway if you want an app that pulls out your data by API, that should be pretty easy on the client side. I guess it would be nice if Lemmy itself offered it as a web service.