@movq@www.uninformativ.de @falsifian@www.falsifian.org @prologic@twtxt.net Maybe I donāt know what Iām talking about and Youāve probably already read this: Everything you need to know about the āRight to be forgottenā coming straight out of the EUās GDPR Website itself. It outlines the specific circumstances under which the right to be forgotten applies as well as reasons that trump the oneās right to erasure ā¦etc.
Iām no lawyer, but my uneducated guess would be that:
A) twts are already publicly available/public knowledge and such⦠just donāt process childrenās personal data and MAYBE youāre good? Since thereās this:
⦠an organizationās right to process someoneās data might override their right to be forgotten. Here are the reasons cited in the GDPR that trump the right to erasure:
- The data is being used to exercise the right of freedom of expression and information.
- The data is being used to perform a task that is being carried out in the public interest or when exercising an organizationās official authority.
- The data represents important information that serves the public interest, scientific research, historical research, or statistical purposes and where erasure of the data would likely to impair or halt progress towards the achievement that was the goal of the processing.
B) What I love about the TWTXT sphere is itās Human/Humane element! No deceptive algorithms, no Corpo B.S ā¦etc. Just Humans. So maybe ⦠If we thought about it in this way, it wouldnāt heart to be even nicer to others/offering strangers an even safer space.
I could already imagine a couple of extreme cases where, somewhere, in this peaceful world oneās exercise of freedom of speech could get them in Real trouble (if not danger) if found out, it wouldnāt necessarily have to involve something to do with Law or legal authorities. So, If someone asks, and maybe fearing fearing for⦠letās just say āTheir well beingā, would it heart if a pod just purged their content if itās serving it publicly (maybe relay the info to other pods) and call it a day? It doesnāt have to be about some law/convention somewhere ⦠𤷠I know! Too extreme, but Iāve seen news of people whoād gone to jail or got their lives ruined for as little as a silly joke. And it doesnāt even have to be about any of this.
P.S: Maybe make X tool check out robots.txt? Or maybe make long-term archives Opt-in? Opt-out?
P.P.S: Already Way too many MAYBEās in a single twt! So Iāll just shut up. š
Bahahahaha very clever @lyse@lyse.isobeef.org I look forward to reading your report ! 𤣠Howeverā¦
$ yarnc debug https://twtxt.net/user/prologic/twtxt.txt | grep -E '^pqst4ea' | tee | wc -l
0
I very quickly proved that Twt was never from me š¤£
@prologic@twtxt.net I have no specifics, only hopes. (I have seen some articles explaining the GDPR doesnāt apply to a āpurely personal or household activityā but I donāt really know what that means.)
I donāt know if itās worth giving much thought to the issue unless either you expect to get big enough for the GDPR to matter a lot (I imagine making money is a prerequisite) or someone specifically brings it up. Unless you enjoy thinking through this sort of thing, of course.
@falsifian@www.falsifian.org Do you have specifics about the GRPD law about this?
Would the GDPR would apply to a one-person client like jenny? I seriously hope not. If someone asks me to delete an email they sent me, I donāt think I have to honour that request, no matter how European they are.
Iām not sure myself now. So letās find out whether parts of the GDPR actually apply to a truly decentralised system? š¤
@lyse@lyse.isobeef.org yeah, tell us, @prologic@twtxt.net, what isnāt true? š¤ You canāt just go around, āthatās not true, and thatās not true; and that, and that!ā without spelling out exactly what isnāt, and why? For the love of god, why?! š
@falsifian@www.falsifian.org comments on the feeds as in nick, url, follow, that kind of thing? If that, then not interested at all. I envision an archive that would allow searching, and potentially browsing threads on a nice, neat interface. You will have to think, though, on other things. Like, what to do with images? Yarn allows users to upload images, but also embed it in twtxts from other sources (hotlinking, actually).
@david@collantes.us Thanks, thatās good feedback to have. I wonder to what extent this already exists in registry servers and yarn pods. I havenāt really tried digging into the past in either one.
How interested would you be in changes in metadata and other comments in the feeds? Iām thinking of just permanently saving every version of each twtxt file that gets pulled, not just the twts. It wouldnāt be hard to do (though presenting the information in a sensible way is another matter). Compression should make storage a non-issue unless someone does something weird with their feed like shuffle the comments around every time I fetch it.
@falsifian@www.falsifian.org āI was actually thinking about making an Internet Archive style twtxt archiver, letting you explore past twtsā ā thatās an awesome idea for a project. Something I would certainly use!
(replyto:ā¦) over (edit:#): (replyto:ā¦) relies on clients always processing the entire feed ā otherwise they wouldnāt even notice when a twt gets updated. a) This is more expensive, b) you cannot edit twts once they get rotated into an archived feed, because there is nothing signalling clients that they have to re-fetch that archived feed.
@movq@www.uninformativ.de I donāt think it has to be like that. Just make sure the new version of the twt is always appended to your current feed, and have some convention for indicating itās an edit and which twt it supersedes. Keep the original twt as-is (or delete it if you donāt want new followers to see it); doesnāt matter if itās archived because you arenāt changing that copy.
@prologic@twtxt.net Do you have a link to some past discussion?
Would the GDPR would apply to a one-person client like jenny? I seriously hope not. If someone asks me to delete an email they sent me, I donāt think I have to honour that request, no matter how European they are.
I am really bothered by the idea that someone could force me to delete my private, personal record of my interactions with them. Would I have to delete my journal entries about them too if they asked?
Maybe a public-facing client like yarnd needs to consider this, but that also bothers me. I was actually thinking about making an Internet Archive style twtxt archiver, letting you explore past twts, including long-dead feeds, see edit histories, deleted twts, etc.
@prologic@twtxt.net what time in UTC?
@prologic@twtxt.net cool, I will be there! Are you going to post the regular banner notice? It will serve as a reminder, at least for me.
@lyse@lyse.isobeef.org I donāt think this is true.
@david@collantes.us Well, I wouldnāt recommend using my code for your main jenny use anyway. If you want to try it out, set XDG_CONFIG_HOME and XDG_CACHE_HOME to some sandbox directories and only run my code there. If @movq@www.uninformativ.de is interested in any of this getting upstreamed, Iād be happy to try rebasing the changes, but otherwise itās a proof of concept and fun exercise.
@falsifian@www.falsifian.org hiya from the Sunshine State (also known as a never-ending hell, LOL)!
@falsifian@www.falsifian.org this one hits hard, as jenny was just updated today. :ā-(
@david@collantes.us Hello!
@prologic@twtxt.net Hi. i have noticed sometimes when i hit the back button i lose all the surrounding layout and just have a list of twts.

I wrote some code to try out non-hash reply subjects formatted as (replyto ), while keeping the ability to use the existing hash style.
I donāt think we need to decide all at once. If clients add support for a new method then people can use it if they like. The downside of course is that this costs developer time, so I decided to invest a few hours of my own time into a proof of concept.
With apologies to @movq@www.uninformativ.de for corrupting jennyās beautiful code. I donāt write this expecting you to incorporate the patch, because it does complicate things and might not be a direction you want to go in. But if you like any part of this approach feel free to use bits of it; I release the patch under jennyās current LICENCE.
Supporting both kinds of reply in jenny was complicated because each email can only have one Message-Id, and because itās possible the target twt will not be seen until after the twt referencing it. The following patch uses an sqlite database to keep track of known (url, timestamp) pairs, as well as a separate table of (url, timestamp) pairs that havenāt been seen yet but are wanted. When one of those āwantedā twts is finally seen, the mail file gets rewritten to include the appropriate In-Reply-To header.
Patch based on jenny commit 73a5ea81.
https://www.falsifian.org/a/oDtr/patch0.txt
Not implemented:
- Composing twts using the (replyto ā¦) format.
- Probably other important things Iām forgetting.
@lyse@lyse.isobeef.org indeed! There is no ācentral authorityā acting as witness, and notary. The more I think of it⦠LOL.
@movq@www.uninformativ.de I recognise him, but yes, he has aged quite a bit. I mean, I look at myself in the mirror and canāt, often, recognise myself. Ageing is a bitch! š
compressed_subject(msg_singlelined) be configurable, so only a certain number of characters get displayed, ending on ellipses? Right now the entire twtxt is crammed into the Subject:. This request aims to make twtxts display on mutt/neomutt, etc. more like emails do.
@movq@www.uninformativ.de perfect in every way. Configurable too! Thank you!
compressed_subject(msg_singlelined) be configurable, so only a certain number of characters get displayed, ending on ellipses? Right now the entire twtxt is crammed into the Subject:. This request aims to make twtxts display on mutt/neomutt, etc. more like emails do.
@movq@www.uninformativ.de yes, thatās perfect! <3
@eldersnake@we.loveprivacy.club I wanted to ask you, are you running Headscale and WireGuard on the same VPS? I want to test Headscale, but currently run a small container with WireGuard, and I wonder if I need to stop (and eventually get rid of) the container to get Headscale going. Did you use the provided .deb to install Headscale, or some other method?
@prologic@twtxt.net I read it. I understand it. Hopefully a solution can be agreed upon that solves the editing issue, whilst maintaining the cryptographic hash.
Can I get someone like maybe @xuu@txt.sour.is or @abucci@anthony.buc.ci or even @eldersnake@we.loveprivacy.club ā If you have some spare time ā to test this yarnd PR that upgrades the Bitcask dependency for its internal database to v2? š
VERY IMPORTANT If you do; Please Please Please backup your yarn.db database first! š
Heaven knows I donāt want to be responsible for fucking up a production database here or there š¤£
@prologic@twtxt.net I know the role of the current hash is to allow referencing (replies and, thus, threads), and it also represents a āuniqueā way to verify a twtxt hasnāt been tampered with. Is that second so important, if we are trying to allow edits? I know if feels good to be able to verify, but in reality, how often one does it?
@movq@www.uninformativ.de could it be possible to have compressed_subject(msg_singlelined) be configurable, so only a certain number of characters get displayed, ending on ellipses? Right now the entire twtxt is crammed into the Subject:. This request aims to make twtxts display on mutt/neomutt, etc. more like emails do.
@prologic@twtxt.net I donāt trust Google with anything, sorry, pass. Oh, and you need to sign in on your Google Account (or whatever they call it these days).
@prologic@twtxt.net how about hashing a combination of nick/timestamp, or url/timestamp only, and not the twtxt content? On edit those will not change, so no breaking of threads. I know, I know, just adding noise here. :-P
@eldersnake@we.loveprivacy.club there has to be less reliance on a single point of failure. It is not so much about creating jobs in the US (which come with it, anyway), but about the ability to produce whatās needed at home too. Whatās the trade off? Is it going to be a little bit more expensive to manufacture, perhaps?
@prologic@twtxt.net Thatās definitely a little less depressing, when thinking of it that way 𤣠Be interesting when the hype dies down.
@quark@ferengi.one It does not. That is why Iām advocating for not using hashes for treads, but a simpler link-back scheme.
@prologic@twtxt.net where was that idea?
@prologic@twtxt.net the basic idea was to stem the hash.. so you have a hash abcdef0123456789... any sub string of that hash after the first 6 will match. so abcdef, abcdef012, abcdef0123456 all match the same. on the case of a collision i think we decided on matching the newest since we archive off older threads anyway. the third rule was about growing the minimum hash size after some threshold of collisions were detected.
@prologic@twtxt.net Wikipedia claims sha1 is vulnerable to a āchosen-prefix attackā, which I gather means I can write any two twts I like, and then cause them to have the exact same sha1 hash by appending something. I guess a twt ending in random junk might look suspcious, but perhaps the junk could be worked into an image URL like
. If thatās not possible now maybe it will be later.
git only uses sha1 because theyāre stuck with it: migrating is very hard. There was an effort to move git to sha256 but I donāt know its status. I think there is progress being made with Game Of Trees, a git clone that uses the same on-disk format.
I canāt imagine any benefit to using sha1, except that maybe some very old software might support sha1 but not sha256.
@prologic@twtxt.net :-D Thanks! Things can come in cycles, right? This is simply another one. Another cycle, more personal than the other āalter egosā.
@aelaraji@aelaraji.com hey, hey! You are my very first reply! šš» Cheers!
@david@collantes.us āHello backā from the other corner of the world! š«”
Alright. My first mentionsāwhich were picked not so randomly, LOLāare @prologic@twtxt.net, @lyse@lyse.isobeef.org, and @movq@www.uninformativ.de. I am also posting my first image too, which you see below. Thatās my neighbourhood, in a āwinterā day. Hopefully @prologic@twtxt.net will add my domain to his allowed list, so that the image (and any other further) renders.

I have configured my twtxt.txt as simple as possible. I have setup a publish_command on jenny. Hopefully all works fine, and I am good to go. Next will be setting the announce_me to true. Here we go!
@sorenpeter@darch.dk hmm, how does your client handles āa little editingā? I am sure threads would break just as well. š
@prologic@twtxt.net, there is a parser bug on parent. Specifically on this portion:
"*If twtxt/Yarn was to grow bigger, then this would become a concern again. *But even Mastodon allows editing*, so how
+much of a problem can it really be? š
*"
@movq@www.uninformativ.de going a little sideways on this, ā*If twtxt/Yarn was to grow bigger, then this would become a concern again. But even Mastodon allows editing, so how much of a problem can it really be? š *ā, wouldnāt it preparing for a potential (even if very, very, veeeeery remote) growth be a good thing? Mastodon signs all messages, keeps a history of edits, and it doesnāt break threads. It isnāt a problem there.š It is here.
I think keeping hashes is a must. If anything for that āfeels goodā feeling.
@movq@www.uninformativ.de Agreed that hashes have a benefit. I came up with a similar example where when I twted about an 11-character hash collision. Perhaps hashes could be made optional somehow. Like, you could use the āreplytoā idea and then additionally put a hash somewhere if you want to lock in which version of the twt you are replying to.
Hey, @movq@www.uninformativ.de, a tiny thing to add to jenny, a -v switch. That way when you twtxt āThatās an older format that was used before jenny version v23.04ā, I can go and run jenny -v, and āduh!ā myself on the way to a git pull. :-D
@movq@www.uninformativ.de ooooh, nice! commit 62a2b7735749f2ff3c9306dd984ad28f853595c5:
Crawl archived feeds in āfetch-context
Like, very much! :-)
@movq@www.uninformativ.de to paraphrase US Presidents speech on each State of the Union, āthe State of the Jenny is strong!ā :-D As for the potential upcoming changes, there has to be a knowledgeable head honcho that will agglomerate and coalesce, and guide onto the direction that will be taken. All that with the strong input from the developers that will be implementing the changes, and a lesser (but not less valuable) input from users.
@lyse@lyse.isobeef.org I call upon the services of the @yarn_police@twtxt.net to further investigate this oddness!
@quark@ferengi.one Oh, sure, it would be nice if edits didnāt break threads. I was just pondering the circumstances under which I get annoyed about data being irrecoverably deleted or otherwise lost.