@xuu it’s not really strictly required if we’re just talking about identity though right? If we’re talking about encryption then yes I agree rotate and keys becomes very important if you want to have attributes like perfect forward secrecy.

@xuu that could work too, but that requires a random value, a set of keys and signature verification of the value, which I don’t really have a problem with.

@xuu yes I’m less concerned about solving the integrity part of the problem of whether we can trust that the content of a feed is actually written by certain author, however, that’s not to say that we shouldn’t think about also leveraging keys to be able to do that maybe it’s an optional feature?

What were the recommended mitigations?

@sorenpeter@darch.dk There was a client that would generate a unique hash for each twt. It didn’t get wide adoption.

@prologic@twtxt.net identity and content integrity are two different problems.

Key rotation is a very important feature in a system like this.

the right way to solve this is to use public/private key(s) where you actually have a public key fingerprint as your feed’s unique identity that never changes.

i would rather it be a random value signed by a key. That way the key can change but the value stays the same.

Interesting.. QUIC isn’t very quick over fast internet.

QUIC is expected to be a game-changer in improving web application performance. In this paper, we conduct a systematic examination of QUIC’s performance over high-speed networks. We find that over fast Internet, the UDP+QUIC+HTTP/3 stack suffers a data rate reduction of up to 45.2% compared to the TCP+TLS+HTTP/2 counterpart. Moreover, the performance gap between QUIC and HTTP/2 grows as the underlying bandwidth increases. We observe this issue on lightweight data transfer clients and major web browsers (Chrome, Edge, Firefox, Opera), on different hosts (desktop, mobile), and over diverse networks (wired broadband, cellular). It affects not only file transfers, but also various applications such as video streaming (up to 9.8% video bitrate reduction) and web browsing. Through rigorous packet trace analysis and kernel- and user-space profiling, we identify the root cause to be high receiver-side processing overhead, in particular, excessive data packets and QUIC’s user-space ACKs. We make concrete recommendations for mitigating the observed performance issues.

https://dl.acm.org/doi/10.1145/3589334.3645323

@movq@www.uninformativ.de Yeah, public transport is great if it works. All too often, it just doesn’t, though. :-( Unfortunately, for my trips to the offices, it’s always slower than a car.

That website looks like one I would build. :‘-D I just always go to bahn.de. It even works alright if the train is operated by another company. At least it’s good enough for my connections (VVS, Arverio, Ding & Co.). When GoAhead took over the line from DB, their delay/cancel information on their own website were just as bad as the one relayed by DB most of the time.

@movq@www.uninformativ.de @bender@twtxt.net That was indeed a funny adventure. I really had to laugh about the mess on the floor I made. :-D

Speaking of public transportation, though: If it works, then it’s an amazing system. I love it.

I recently took the time to find an alternative route to one of my doctors. Hardly any people using that route and it’s faster. Absolutely brilliant. It’s like having a chauffeur. 😅

But navigating through that system is also a total nightmare. Which bus takes you to which places at which times, getting info about current construction sites, all that stuff. It takes forever.

And it doesn’t help at all that this is what their website looks like:

https://movq.de/v/acb23dc1c2/s.png

You can’t move that window at the bottom. It just sits there and takes up space from the map. It gets even worse: When you ask for a route, you get to see the buses and individual stops and all that – but all in that little window with that large font! Why do we all have widescreen monitors and than stack UI items vertically?

Sure, 30 years ago it was much worse. But it could also be much better today. 😅

@lyse@lyse.isobeef.org talk about an epic adventure! :-D

@lyse@lyse.isobeef.org Gosh, that sounds so horrible. 🙈🤢

Another idea for the upcoming Advent Of Code 2024:

OS/2 Warp 4 came with Java and that not only meant a runtime but a JDK including API docs. So, for AoC, I could try to solve as many puzzles as I can in that environment, directly on my old Pentium. For later puzzles, I’ll definitely want to switch to my normal workstation for faster development cycles – but I can still use Java and try to backport the solutions.

Sounds interesting. 🤔

https://movq.de/v/81ac0142f2/1.ff.jpg
https://movq.de/v/81ac0142f2/2.ff.jpg

@movq@www.uninformativ.de Right!

The knowledge gain was still very limited, but it actually turned out a little better than I thought. Talking to the people face to face was really nice. And we also had a surprise barbie in the end, so it was worth coming. :-D

Also, the train connections worked out. Just on the way back, I made the error to use the toilet in the train. I’ve experienced way worse, but there was certainly a little Urine odor in the air. Second thing I noted was a large pile of toilet paper in the bowl.

When I wanted to wash my hands, I got the soap dispenser to work, but the tap just dripped extremely slowly. Not usable. Then it clicked why there was all this paper in the loo. I tried to wipe the soap off with toilet paper as best as I could and then used my water bottle to rinse my hands. Luckily, I had topped it off before I left the office. I only had to use my jumper to increase grip for actually getting the lid off. The sparkling water happily soaked my jumper and the floor in an instant. :-D

Tip for your next train ride: Bring your own water supply, preferably non-carbonated. Alternatively, just use the office toilet beforehand.

Turns out that at least this train model has two separate water tanks. One for the faucet and another for the loo. I flushed the paper without issues before I left.

@aelaraji@aelaraji.com Yeah, that’s pretty close to what was outlined here: https://twtxt.net/twt/ansuy4a 😅

So this is a great thread. I have been thinking about this too.. and what if we are coming at it from the wrong direction? Identity being tied to a given URL has always been a pain point. If i get a new URL its almost as if i have a new identity because not only am I serving at a new location but all my previous communications are broken because the hashes are all wrong.

What if instead we used this idea of signatures to thread the URLs together into one identity? We keep the URL to Hash in place. Changing that now is basically a no go. But we can create a signature chain that can link identities together. So if i move to a new URL i update the chain hosted by my primary identity to include the new URL. If i have an archived feed that the old URL is now dead, we can point to where it is now hosted and use the current convention of hashing based on the first url:

The signature chain can also be used to rotate to new keys over time. Just sign in a new key or revoke an old one. The prior signatures remain valid within the scope of time the signatures were made and the keys were active.

The signature file can be hosted anywhere as long as it can be fetched by a reasonable protocol. So say we could use a webfinger that directs to the signature file? you have an identity like frank@beans.co that will discover a feed at some URL and a signature chain at another URL. Maybe even include the most recent signing key?

From there the client can auto discover old feeds to link them together into one complete timeline. And the signatures can validate that its all correct.

I like the idea of maybe putting the chain in the feed preamble and keeping the single self contained file.. but wonder if that would cause lots of clutter? The signature chain would be something like a log with what is changing (new key, revoke, add url) and a signature of the change + the previous signature.

# chain: ADDKEY kex14zwrx68cfkg28kjdstvcw4pslazwtgyeueqlg6z7y3f85h29crjsgfmu0w 
# sig: BEGIN SALTPACK SIGNED MESSAGE. ... 
# chain: ADDURL https://txt.sour.is/user/xuu
# sig: BEGIN SALTPACK SIGNED MESSAGE. ...
# chain: REVKEY kex14zwrx68cfkg28kjdstvcw4pslazwtgyeueqlg6z7y3f85h29crjsgfmu0w
# sig: ...

IMO we just have to fix the identity problem and figure out how to detect or support edits.

@sorenpeter@darch.dk No, this is what I want to avoid. For many reasons I stated before, content addressing or hashing is far better here for threading in a decentralized way.

@prologic@twtxt.net do that mean that for every new post (not replies) the client will have to generate a UUID or similar when posting and add that to to the twt?

Merci, @movq@www.uninformativ.de! I will keep you posted. :-)

@movq@www.uninformativ.de Same here for sure. :-D Great, I just saw the start was postponed by yet another half hour. I could have slept longer. Well, gonna catch the later train then.

@prologic@twtxt.net yup.

@lyse@lyse.isobeef.org I personally think that we just go with a magic timestamp approach. It’s simpler and easier to implement across the major clients that are still actively developed.

The question is how much time do we give ourselves as we’re all a bit time poor and I can’t imagine we would do this quickly.

@movq@www.uninformativ.de if you do win the lottery, don’t forget to include us so we can all join in and share the things that we like to tinker with instead of this whole rat race. 🤣

@bender@twtxt.net Big photo capability upgrade?

@aelaraji@aelaraji.com Nice hack! 👌

@prologic@twtxt.net iPhone 16 Pro Max for you, for sure. If significant other likes to take pictures as much as mine, then one for her too. That’s $1,200 each (with 256GB storage).

I went straight to bed after posting this and slept for 3 hours. 😩 Can’t I just win the lottery and be done with this whole “money” thing? 🤪

@lyse@lyse.isobeef.org Oof, well, good luck. Those multi-day meetings are usually really exhausting (and mostly pointless) in our company, hopefully it’s different at yours. ✌️

@lyse@lyse.isobeef.org Indeed, great news! If you need testers at some point, let me know. 😅

Lest we forget … https://www.youtube.com/watch?v=mp5gksq_OEI … !

@falsifian@www.falsifian.org Regarding your last paragraph: Back in December 2020, we already once changed the hashing. I think that was my first contribution, breaking everything by switching to RFC 3339 for the timestamp format. ;-) I’m computing two hashes in my client, the old and current one. And then I just select whatever matching parent exists to build the thread tree.

I could do that again in my client, but you’re right, it’s a different story for jenny. If I’m not mistaken, In-Reply-To could contain several hashes, but the Message-ID header is the issue.

By increasing the hash length for a potential future change, clients could tell, which algorithm to use.

Maybe we could define a magic timestamp in the future that marks the cutoff point. Use the current implementation for messages authored before that magic date or the new algorithm for all messages after that.

But eventually, all clients have to be updated. There’s no way around that, I believe. Simplicity is key and my magic time already adds complexity. :-/

@movq@www.uninformativ.de @aelaraji@aelaraji.com @bender@twtxt.net Why not have both Jupiter and Venus together? https://www.youtube.com/watch?v=oXyCORLeLd0 I don’t understand anything either, but it just sounds great to my ears.

if not I am editing and breaking replies!

Bwahahahaaa! :‘-D

@bender@twtxt.net I doubt I’ll be able to watch it live 🤣 But by all means, please Yarns all the goodies 😅

Nice, thanks for the offer, @bender@twtxt.net! You have to be a bit patient, though, it’ll take a while until there is something to actually worth messing with. :-)

Getting ready for the Apple Event. Are you watching it live, @prologic@twtxt.net, or afterwards? :-P

@movq@www.uninformativ.de @prologic@twtxt.net :-D

It’s like that for months. :-( And tomorrow I even gotta go into the office for some two day meeting, but I only attend a single day. On the positive side, I’m gonna see some workmates that I haven’t ever met in the real world or for a very long time.

@bender@twtxt.net Kind of mirrored the ssh and ssh-keygen utilities. No reason really.

@bender@twtxt.net

$ echo 'hello world' | ./salty -i ./test_ed25519 --ssh-key --sign

@prologic@twtxt.net any reason why there is salty, and salty-keygen? Why not both into one?

@prologic@twtxt.net hey, what’s the one liner to sign using an SSH key with salty?

@bender@twtxt.net Ahh yeah sorry about that 🤣 You were getting confused between salty.im and salty. The later of which salty.im actually uses and formed the basis of everything else. It’s a simple robust library and command-line tools with good test coverage. The lowest building block 😅

I think I know what I did wrong. LOL. I used the wrong repository. Going for go install go.mills.io/salty/cmd/salty@latest instead. Duh!

@prologic@twtxt.net So, I did go install go.salty.im/saltyim/cmd/salty-chat@latest, moved salty-chat to my bin as salty, and that one liner isn’t working. What am I doing wrong?

@prologic@twtxt.net excellent, thanks!

@movq@www.uninformativ.de That bad eh? 😅

It’s one of those days.

For example:

$ echo 'hello world' | ./salty -i ./test.key -s | ./salty -i ./test.key -v
# signed by: kex1yfzzthmsdlqhgwzafy9zpjze6a0asxf6y552dp4yhvq66a4jje0qxqapvd
hello world