In-reply-to » Iā€™m still more in favor of (replyto:ā€¦). Itā€™s easier to implement and the whole edits-breaking-threads thing resolves itself in a ā€œnaturalā€ way without the need to add stuff to the protocol.

I just realized the other big property you lose is:

What if someone completely changes the content of the root of the thread?

Does the Subject reference the feed and timestamp only or the intent too?

ā¤‹ Read More
In-reply-to » Iā€™m still more in favor of (replyto:ā€¦). Itā€™s easier to implement and the whole edits-breaking-threads thing resolves itself in a ā€œnaturalā€ way without the need to add stuff to the protocol.

@bender@twtxt.net Yeah Iā€™ll be honest here; Iā€™m not going to be very happy if we go down this ā€œlocation addressingā€ route;

  • Twt Subjects lose their meaning.
  • Twt Subjects cannot be verified without looking up the feed.
    • Which may or may not exist anymore or may change.
  • Two persons cannot reply to a Twt independently of each other anymore.

and probably some other properties weā€™d stand to lose that Iā€™m forgetting aboutā€¦

ā¤‹ Read More
In-reply-to » Iā€™m still more in favor of (replyto:ā€¦). Itā€™s easier to implement and the whole edits-breaking-threads thing resolves itself in a ā€œnaturalā€ way without the need to add stuff to the protocol.

I like the (replyto:...) as well. If the feed changes, well, it is the same as changing emails (and deleting the old one). No?

ā¤‹ Read More
In-reply-to » Iā€™m still more in favor of (replyto:ā€¦). Itā€™s easier to implement and the whole edits-breaking-threads thing resolves itself in a ā€œnaturalā€ way without the need to add stuff to the protocol.

@movq@www.uninformativ.de One of the biggest reasons I donā€™t like the (replyto:ā€¦) proposal (location addressing vs. content addressing) is that you just introduce a similar problem down the track, albeit rarer where if a feed changes its location, your threadā€™s ā€œidentifiersā€ are no longer valid, unless those feed authors maintain strict URL redirects, etc. This potentially has the long-term effect of being rather fragile, as opposed to what we have now where an Edit just really causes a natural fork in the thread, which is how ā€œforkingā€ works in the first place.

I realise this is a bit pret here, and it probably doesnā€™t matter a whole lot at our size. But Iā€™m trying to think way ahead, to a point where Twtxt as a ā€œthingā€ can continue to work and function decades from now, even with the extensions weā€™ve built. Weā€™ve already proven for example that Twts and threads from ~4 years ago still work and are easily looked up haha šŸ˜

ā¤‹ Read More
In-reply-to » Alright, before I go and watch Formula 1 šŸ˜…, I made two PRs regarding the two ā€œcompetingā€ ideas:

I just read the primary spec Iā€™m strongly in support of and itā€™s pretty rock solid for me šŸ‘Œ šŸ’Æ

ā¤‹ Read More

Ever wondered what it would cost to self-hosted vs. use the cloud? Well I often doubt myself every time I look at hardware prices, and I know I have to do some hardware refresh soonā„¢ for the Mills DC (something I donā€™t have a regular plan or budget for), hereā€™s a rough ball park:

The Mills DC has cost me around ~$15k to build and maintain over the last ~10 years or so. Roughly speaking. Iā€™ve never actually taken a Bill of Materials or anything, but I could if anyone is interested in more specifics.

The equivalent of resources if run in the ā€œCloudā€ would cost around:

  • ~$1,000 for virtual machines
  • ~$12000 for storage

So around ~$2,000/month to run.

Keep this in mind anytime anyone ever tries to con you into believing ā€œCloud is cheaperā€. Itā€™s not.

ā¤‹ Read More
In-reply-to » @movq @falsifian @prologic 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.

@aelaraji@aelaraji.com This is one of the reasons why yarnd has a couple of settings with some sensible/sane defaults:

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.

There are two settings:

$ ./yarnd --help 2>&1 | grep max-cache
      --max-cache-fetchers int        set maximum numnber of fetchers to use for feed cache updates (default 10)
  -I, --max-cache-items int           maximum cache items (per feed source) of cached twts in memory (default 150)
  -C, --max-cache-ttl duration        maximum cache ttl (time-to-live) of cached twts in memory (default 336h0m0s)

So yarnd pods by default are designed to only keep Twts around publicly visible on either the anonymous Frontpage or Discover View or your Timeline or the feedā€™s Timeline for up to 2 weeks with a maximum of 150 items, whichever get exceeded first. Any Twts over this are considered ā€œoldā€ and drop off the active cache.

Itā€™s a feature that my old man @off_grid_living@twtxt.net was very strongly in support of, as was I back in the day of yarndā€™s design (nothing particularly to do with Twtxt per se) that Iā€™ve to this day stuck by ā€“ Even though there are some šŸ˜‰ that have different views on this šŸ¤£

ā¤‹ Read More
In-reply-to » @falsifian Do you have specifics about the GRPD law about this?

@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. šŸ˜…

ā¤‹ Read More
In-reply-to » Another thing: At the moment, anyone could claim that some feed contained a certain message which was then removed again by just creating the hash over the fake message in said feed and invented timestamp themselves. Nobody can ever verify that this was never the case in the first place and completely made up. So, our twt hashes have to be taken with a grain of salt.

@movq@www.uninformativ.de Yes thatā€™s true they are only integrity checks. But beyond a malicious pod (ignore yarndā€™a gossiping protocol for now) how does what @lyse@lyse.isobeef.org presented work exactly? šŸ˜…

ā¤‹ Read More
In-reply-to » @falsifian Do you have specifics about the GRPD law about this?

This has specifically come up before in the form of ā€œinformal complaintsā€ against yarnd because of the way it permanently stores and archives Twts, so even if you decide you changed your mind, or deleted that line out of your feed, if my pod or @xuu@txt.sour.is or @abucci@anthony.buc.ci or @eldersnake@we.loveprivacy.club (or any other handful of pods still around?) saw the Twt, itā€™d be permanently archived.

ā¤‹ Read More
In-reply-to » @falsifian Do you have specifics about the GRPD law about this?

Yeah Iā€™m curious to find out too beyond just ā€œhere sayā€. But regardless of whether we should or shouldnā€™t care about this or should or shouldnā€™t comply. We should IMO. Iā€™d have to build something that horrendously violates someoneā€™s rights in another country.

ā¤‹ Read More
In-reply-to » Another thing: At the moment, anyone could claim that some feed contained a certain message which was then removed again by just creating the hash over the fake message in said feed and invented timestamp themselves. Nobody can ever verify that this was never the case in the first place and completely made up. So, our twt hashes have to be taken with a grain of salt.

@movq@www.uninformativ.de Care to explain how this explicit/attack works for me? šŸ¤£

ā¤‹ Read More
In-reply-to » I've also put up this PR Add compatible methods for Index to behave as the Archiver (transition) #1177 that will act as a transition from the old naive archiver to the new bluge-based search/index. I will switch my pod over to this soon to test it before anyone else does.

Well that was bloody awful. This PR bokr my pod for some strange reason I canā€™t figure out why or how šŸ˜± The process just kept getting terminated from something, somewhere (no panic). weird. Iā€™ve reverted this PR for now @xuu@txt.sour.is

ā¤‹ Read More
In-reply-to » @falsifian Do you have specifics about the GRPD law about this?

@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.

ā¤‹ Read More
In-reply-to » And we're back. Sorry about that šŸ˜…

For those curious, the archive on this pod had reached around ~22GB in size. I had to suck it down to my more powerful Mac Studio to clean it up and remove a bunch of junk. Then copy all the data back. This is what my local network traffic looked like for the last few hours šŸ˜±

ā¤‹ Read More
In-reply-to » Another thing: At the moment, anyone could claim that some feed contained a certain message which was then removed again by just creating the hash over the fake message in said feed and invented timestamp themselves. Nobody can ever verify that this was never the case in the first place and completely made up. So, our twt hashes have to be taken with a grain of salt.

@lyse@lyse.isobeef.org Hmmm Iā€™m not sure sure I get what youā€™re getting at here. In order for this to be true, yarnd would have to be maliciously fabricating a Twt with the Hash D.

ā¤‹ Read More

The monthly reading tag for #September is #school, and I thought I would be reading fiction for it. But fate decided that the book in the picture would be released this month, so here am I fulfilling the thread by reading a non-fiction book about the high-school I attended to, a book I participate with along others that help form a collective memory spanning five decades - I am the youngest participant, having graduated from this high-school in 1999.

#fridayreads #bookstodon

Image

ā¤‹ Read More
In-reply-to » @movq Thanks for the summary!

If OTOH your client doesnā€™t store individual Twts in a cache/archive or some kind of database, then verification becomes quite hard and tedious. However I think of this as an implementation details. The spec should just call out that clients must validate/verify the edit request and the matching hash actually exists in that feed, not how the client should implement that.

ā¤‹ Read More
In-reply-to » @movq Thanks for the summary!

@lyse@lyse.isobeef.org Yes you do. You keep both versions in your cache. They have different hashes. So you have Twt A, a client indicates Twt B is an edit of A, your client has already seen A and cached and archived it, now your client fetches B which is indicated of editing A. You cache/archive B as well, but now indicate in your display that B replaces A (maybe display, link both) or just display B or whatever. But essentially you now have both, but an indicator of one being an edit of the other.

The right thing to do here of course is to keep A in the ā€œthreadā€ but display B. Why? So the thread/chain doesnā€™t actually break or fork (forking is a natural consequence of editing, or is it the other way around? šŸ¤”).

ā¤‹ Read More
In-reply-to » It just occurs to me we're now building some kind of control structures or commands with (edit:ā€¦) and (delete:ā€¦) into feeds. It's not just a simple "add this to your cache" or "replace the cache with this set of messages" anymore. Hmm. We might need to think about the consequences of that, can this be exploited somehow, etc.

@lyse@lyse.isobeef.org Iā€™m all for dropping delete btw, Or at least not making it mandatory, as-in ā€œclients shouldā€ rather than ā€œclients mustā€. But yes I agree, letā€™s explore all the possible ways this can be exploited (if at all).

ā¤‹ Read More
In-reply-to » Another thing: At the moment, anyone could claim that some feed contained a certain message which was then removed again by just creating the hash over the fake message in said feed and invented timestamp themselves. Nobody can ever verify that this was never the case in the first place and completely made up. So, our twt hashes have to be taken with a grain of salt.

@lyse@lyse.isobeef.org Walk me through this? šŸ¤” I get what youā€™re saying, but Iā€™m too stupid to be a ā€œhackerā€ šŸ¤£

ā¤‹ Read More
In-reply-to » @david 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.

@lyse@lyse.isobeef.org @falsifian@www.falsifian.org Contributions to search.twtxt.net, which runs yarns (not to be confused with yarnd) are always welcome šŸ¤— ā€“ I donā€™t have as much ā€œspare timeā€ as I used to due to the nature of my job (Staff Engineer); but I try to make improvements every now and again šŸ’Ŗ

ā¤‹ Read More
In-reply-to » @prologic Do you have a link to some past discussion?

@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? šŸ¤”

ā¤‹ Read More
In-reply-to » @lyse I don't think this is true.

LOL šŸ˜‚ This:

anyone could claim that some feed contained a certain message which was then removed again by just creating the hash over the fake message in said feed and invented timestamp themselves

Iā€™d like to see a step-by-step reproduction of this. I donā€™t buy it šŸ¤£

Admittedly yarnd had a few implementation security bugs, but Iā€™m not sure this is actually possible, unless Iā€™m missing something? šŸ¤”

ā¤‹ Read More
In-reply-to » @prologic Do you have a link to some past discussion?

@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).

ā¤‹ Read More
In-reply-to » @prologic Do you have a link to some past discussion?

@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.

ā¤‹ Read More
In-reply-to » @eldersnake 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?

I ended up installing Headscale on my little VPS. Just in case the collide, I turned off WireGuard. Turning that one off (which ran on a container) also frees some memory. Headscale is running quite well! Indeed, I have struggled getting any web management console to work, but it really isnā€™t needed. Everything needed to commandeer the server is available through the CLI.

ā¤‹ Read More
In-reply-to » One distinct disadvantage of (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.

ā¤‹ Read More
In-reply-to » @prologic I wouldn't want my client to honour delete requests. I like my computer's memory to be better than mine, not worse, so it would bug me if I remember seeing something and my computer can't find it.

@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.

ā¤‹ Read More
In-reply-to » Okay, the recently implemented --fetch-context, which asks a Yarn pod for a twt, wouldnā€™t break, but jenny would not be able anymore to verify that it actually got the correct twt. Thatā€™s a concrete example where we would lose functionality.

@movq@www.uninformativ.de Hmmm not sure what I was thinking sorry šŸ¤¦ā€ā™‚ļøbeen a long day šŸ˜‚

ā¤‹ Read More
In-reply-to » @prologic 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 kinda click a yarn then a fork and the back button. i have to do a few goes before it does it.

ā¤‹ Read More
In-reply-to » @prologic I get where you're coming from. But is it really that bad in practice? If you follow any link somewhere in the web, you also don't know if its contents has been changed in the meantime. Is that a problem? Almost never in my experience.

@lyse@lyse.isobeef.org No thatā€™s never a problem because we really only want to ā€œnavigateā€ the web anyway not form threads of xonversation šŸ¤£

ā¤‹ Read More
In-reply-to » Okay, the recently implemented --fetch-context, which asks a Yarn pod for a twt, wouldnā€™t break, but jenny would not be able anymore to verify that it actually got the correct twt. Thatā€™s a concrete example where we would lose functionality.

@movq@www.uninformativ.de this approach also wouldnā€™t work and when that Feed gets archived so youā€™ll be forced to crawl archived feeds at that point.

ā¤‹ Read More
In-reply-to » Trying to sum up the current proposal (keeping hashes):

The important bits missing from this summary (devil is in the details) are two requirements:

  • Clients should order Twts by their timestamp.
  • Clients must validate all edit and delete requests that the hash being indicated belongs to and came from that feed.
  • Client should honour delete requests and delete Twts from their cache/archive.

ā¤‹ Read More