In-reply-to » (#l5452vq) 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 » (#fj7dppq) @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 » (#fj7dppq) @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 » (#fj7dppq) 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 » (#l5452vq) 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 » (#w6f7hpa) @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 » (#6y53k7q) @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 » (#l5452vq) @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 » (#6y53k7q) @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 » (#6y53k7q) @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 » (#vq422aa) @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 » (#ce4g4qa) 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 » (#5vbi2ea) @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 » (#ucgvfmq) 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 » (#l5452vq) @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 » (#ucgvfmq) 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
In-reply-to » (#fj7dppq) For implementations, it would be nice if ā€œupdate twtsā€ always came after the twt they are referring to. So I thought about using this opportunity to mandate append-style feeds. But that’s just me being lazy. Implementations will have to be able to cope with any order, because feeds cannot/should not be trusted. 🫤

@movq@www.uninformativ.de I think the order of the lines in a feed don’t matter as long as we can guarantee the order of Twts. Clients should already be ordering by Timestamp anyway.

⤋ Read More
In-reply-to » (#l5452vq) 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 Sorry could you explain this sifferently?

⤋ Read More

Pelos vistos antigamente havia uma coisa chamada ā€œbaile tipo Cascaisā€. Mas como o mundo subversivo dos anos 50 e 60 em Portugal nĆ£o estĆ” bem documentado, hĆ” zero resultados a uma pesquisa do termo nos motores de busca da Internet… resta-me a imaginação para tirar as conclusƵes (provavelmente erradas) de como seria tal baile.

⤋ Read More
In-reply-to » I wrote some code to try out non-hash reply subjects formatted as (replyto ), while keeping the ability to use the existing hash style.

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

⤋ Read More
In-reply-to » I wrote some code to try out non-hash reply subjects formatted as (replyto ), while keeping the ability to use the existing hash style.

BTW this code doesn’t incorporate existing twts into jenny’s database. It’s best used starting from scratch. I’ve been testing it using a custom XDG_CACHE_HOME and XDG_CONFIG_HOME to avoid messing with my ā€œrealā€ jenny data.

⤋ Read More

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.

⤋ Read More
In-reply-to » (#xghlsva) Location Addressing is fine in smaller or single systems. But when you're talking about large decentralised systems with no single point of control (kind of the point) things like independable variable integrity become quite important.

@lyse@lyse.isobeef.org indeed! There is no ā€œcentral authorityā€ acting as witness, and notary. The more I think of it… LOL.

⤋ Read More
In-reply-to » @movq 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.

I mean, really, it couldn’t get any better. I love it!

Image

⤋ Read More
In-reply-to » @movq 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.

@movq@www.uninformativ.de perfect in every way. Configurable too! Thank you!

⤋ Read More
In-reply-to » @movq 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.

@movq@www.uninformativ.de yes, that’s perfect! <3

⤋ Read More
In-reply-to » (#dxu6n5a) I setup and switched to Headscale last night. It was relatively simple, I spent more time installing a web GUI to manage it to be honest, the actual server is simple enough. The native Tailscale Android app even works with it thankfully.

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

⤋ Read More

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 🤣

⤋ Read More
In-reply-to » Can someone much smarter than me help me figure out a couple of newly discovered deadlocks in yarnd that I think have always been there, but only recently uncovered by the Go 1.23 compiler.

nevermind; I think this might be some changes internally in Go 1.23 and a dependency I needed to update šŸ¤ž

⤋ Read More
In-reply-to » (#v3lkjca) no my fault your client can't handle a little editing ;)

Location Addressing is fine in smaller or single systems. But when you’re talking about large decentralised systems with no single point of control (kind of the point) things like independable variable integrity become quite important.

⤋ Read More
In-reply-to » (#v3lkjca) no my fault your client can't handle a little editing ;)

What is being proposed as a counter to content-addressing is called location-addressing. Two very different approaches, both with pros/cons of course. But a local cannot be verified, the content cannot be be guaranteed to be authenticate in any way, you just have to implicitly trust that the location points to the right thing.

⤋ Read More
In-reply-to » (#v3lkjca) no my fault your client can't handle a little editing ;)

For example, without content-addressing, you’d never have been able to find let alone pull up that ~3yr old Twt of me (my very first), hell I’d even though I lost my first feed file or it became corrupted or something 🤣 – If that were the case, it would actually be possible to reconstruct the feed and verify every single Twt against the caches of all of you 🤣

⤋ Read More
In-reply-to » (#v3lkjca) no my fault your client can't handle a little editing ;)

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

⤋ Read More

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

⤋ Read More
In-reply-to » Speaking of AI tech (sorry!); Just came across this really cool tool built by some engineers at Googleā„¢ (currently completely free to use without any signup) called NotebookLM šŸ‘Œ Looks really good for summarizing and talking to document šŸ“ƒ

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

⤋ Read More

Speaking of AI tech (sorry!); Just came across this really cool tool built by some engineers at Googleā„¢ (currently completely free to use without any signup) called NotebookLM šŸ‘Œ Looks really good for summarizing and talking to document šŸ“ƒ

⤋ Read More
In-reply-to » Apple A16 SoC Now Manufactured In Arizona "Apple has begun manufacturing its A16 SoC at the newly-opened TSCM Fab 21 in Arizona," writes Slashdot reader NoMoreACs. AppleInsider reports: According to sources of Tim Culpan, Phase 1 of TSMC's Fab 21 in Arizona is making the A16 SoC of the iPhone 14 Pro in "small, but significant, numbers. The production is largely a test for the facility at this stage, but more production is expected ... ⌘ Read more

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

⤋ Read More
In-reply-to » Getting a little sick of AI this, AI that. Yes I'll be left behind while everyone else jumps on the latest thing, but I'm not sure I care.

@eldersnake@we.loveprivacy.club Yeah I’m looking forward to that myself 🤣 It’ll be great to see where technology grow to a level of maturity and efficiency where you can run the tools on your own PC or Device and use it for what, so far, I’ve found it to be somewhat decent at; Auto-Complete, Search and Q&A.

⤋ Read More
In-reply-to » Apple A16 SoC Now Manufactured In Arizona "Apple has begun manufacturing its A16 SoC at the newly-opened TSCM Fab 21 in Arizona," writes Slashdot reader NoMoreACs. AppleInsider reports: According to sources of Tim Culpan, Phase 1 of TSMC's Fab 21 in Arizona is making the A16 SoC of the iPhone 14 Pro in "small, but significant, numbers. The production is largely a test for the facility at this stage, but more production is expected ... ⌘ Read more

I’m not the biggest Apple fan around, but that is pretty awesome.

⤋ Read More