Archiving context

[timmc]

There are two closely related features I would be interested in:

• A flag to archive all the ancestors of a toot I've created or interacted with
• The same for descendants of such a toot

Use-cases:

• When I respond to a thread, my toot may not be very meaningful outside of that context. Archiving the thread as well preserves the meaning of my toot. (It would also dramatically aid searchability.)
• When I see a really good thread, I will often only star or boost one or two of the best toots in the thread. But I really want to be able to refer back to the whole thing (which includes toots both preceding and following the ones I interacted with).
  • For this use-case, it would be OK to just collect the ancestors and descendants that are by the same author.
• Often there's really good discussion following a toot that I boost, and I'd love to be able to save that as well (without having to strategically interact with all of the "leaf" toots to ensure an archive).
  • For this use-case, I'd want to archive toots by other authors as well.

Known complications:

• Context can be arbitrarily large—I've seen some huge threads, including one person who just keeps appending their latest memes to one massive permathread—so there would need to be a configurable limit to context depth.
• This would require another collection type to be added to media archiving.

Is this a feature set you'd be open to including?

[kensanata]

I’m afraid that this strays in to creepy hostile archiving territory, so I think I’d want to say “no”. See also #107.

[kensanata]

On the old software wiki that is no longer up, somebody bob wrote:

If I reply to someone for the first time in a thread, their message does not mention me. So the archive only has my post and not the parent. Archiving mentions only captures replies to me. If the conversation builds from there, the subsequent messages are archived because they mention me. But the head is missing. There are a lot of cases where I reply to someone and the context is lost because the server admin deletes all externally authored old messages. So it’s somewhat important to have a copy of what I replied to.

Kind of along the same lines, it would also be useful to store links to external copies of archived messages. E.g. if my admin cleans up and deletes all locally cached external statuses, I don’t just want a copy of the text but it would be useful to visit the message on the external server to see if a more complete copy of the thread is maintained there.

I said at the time: I'm sort of loath to add this feature because I don't want to turn mastodon-archive into a general status archiver. I find the toots that mention you are already not the ones you wrote, so in terms of copyright and moral rights, it seems that making and keeping copies without the author's consent is already shady – to then go up the chain and pull even more statuses with an even more tenuous connection seems to stray even further in that territory. I don't want to do this.

bob had a longer reply discussing the ethics:

Mentions: If Bob mentions Alice, Bob owns the copyright but the msg was directed to Alice & intended for her to receive the msg. Like traditional correspondence I think authors never have an expectation that the recipient will destroy the msg. From a GDPR standpoint, the msg is often about Alice thus she has a right to make a GDPR access request to get that data. OTOH, Bob also has a GDPR right to be forgotten although with microblogging he probably doesn’t assume she kept a copy. Strictly speaking, the GDPR does not apply whatsoever because the people are anonymous. But it’s still perhaps useful to think of situations in the spirit of the GDPR. In principle it might be most fair to sync with the server & if Bob deletes a msg then all copies should be deleted too. OTOH, adding a purge nonexisting command would add complexity to the code & perhaps be heavy on bandwidth & server load.

Favourites: we often favourite posts that mention us as an ack signal. So it’s essentially the same as the rationale for mentions. But sometimes we fav things that don’t mention us. Since Alice fav'ing Bob’s msg sends a signal that Alice liked it, we could perhaps rationalize it due to the signal that Alice liking it is about Alice thus she should have access to it.

Boosts: hmm… we are not archiving boosts, are we? Boosting something in itself is a copyright violation AFAICT, no? OTOH, I think if an author doesn’t want their work replicated (reblogged) they set the visibility to private. So maybe it’s fair to say public and unlisted msgs are implicitly authorized by authors for copying since they know boosting is possible. This same rationale could perhaps apply to all other archive triggers/collections.

Bookmarks: these are maybe a little sketchier than favs because you don’t send a signal that you liked that post, so a bookmark is in no way about yourself. Bookmarks are probably even sketchier than msgs that you replied to.

Parents msgs that don’t mention you: When you reply to someone, pre-microblog days we would quote the other person & quotes are “fair use” under the fair use doctrine because you are publishing commentary & have a right to quote portions that your work refers to. It only gets legally dicey if you were to quote someone’s whole book and then just give a one-liner comment. We omit the quotes only because it’s too bulky for microblogging. Consider what happens when Alice replies to Bob then Bob deletes his msg. He has a right to delete his msg, but then Alice’s post looks out of context & maybe even foolish. One consideration is that Bob’s erasure diminished Alice’s derivitive work. Alice has rights too and on non-microblog mediums the quote would persist even when the original is gone. Sometimes Bob’s erasure of his own msg is purely a deliberate act of sabotage against Alice. He would have kept his msg but sacrificed it to orphan Alice’s work. Of course Bob’s erasure can just as well be legit with no intent to undermine Alice.

I’m not a lawyer.. just trying to shed light on factors to consider.

Another thing to consider is if someone uses public visibility & also hashtags something, then they show some intent to have the stored and searchable perhaps long-term.

Fair points all around! And indeed, all of this is a quagmire: keeping copies of bookmarks, keeping copies of favourites. Syncing with the originals might be one way out. Anonymizing toots where the original is gone might be another. But I suspect there is no easy, automated way out of the quagmire. All I know is that it is tricky and I want less of it – and I definitely don't want more of it.

But yeah, now that you've listed all the problems with archiving, I'm ready to hand the project over to anybody who wants to take it.

[timmc]

Thanks for the reply. I totally understand if you don't want to support it for whatever reason. A few additional thoughts, though:

• If I had a desktop Mastodon client, it would likely be caching everything I interacted with just as a matter of course. There might be a social distinction between "passively" caching and actively fetching things after the fact, but another way to look at it is that I'm trying to make my Mastodon experience more closely resemble what it would be like as a desktop, local-first experience.
  • Or for a more concrete comparison: I use a local email client, so when I subscribe to a mailing list, I automatically end up with copies of people's messages to each other. I think this is generally socially accepted, even for mailing lists that require joining to see the archives, or that don't even keep central archives. Interesting difference in expectations.
• On the legal side, copyright and GDPR are likely red herrings.
  • How copyright applies to federated systems like this (where posts are broadcast out and able to be boosted) is probably entirely unsettled law, but I would bet good money that the courts would find many aspects of copyright to be quite weak in such a system. (The author's so-called moral rights would likely get high protection but the copy/performance/display rights would be weak.)
  • GDPR has an exemption for "purely personal or household activity". I believe that would cover all personal, non-commercial archiving.

But yeah, now that you've listed all the problems with archiving, I'm ready to hand the project over to anybody who wants to take it.

Heh, sorry to have contributed to any additional maintainer-stress. I think it's fine for you to just draw a line and say "not interested, feel free to fork" if there's a feature you just don't want to add for any reason.

(I might make my own fork that archives context, but I'd be very unlikely to implement #107 -- if only just because that seems like scope creep, besides any of the social reasons.)