Já não fazia um toot sobre #traduções há muito tempo…

Image

@prologic@twtxt.net Thanks! I tried 😅

@prologic@twtxt.net No luck so far and it looks like I have plenty of reading to do tomorrow morning. 😅

@xuu@txt.sour.is What’s the keyoxide thingy you wrote/built? 🤔 What’s your URI/profile? 🤔

@aelaraji@aelaraji.com Sounds like it would work 👌 Though I’ve not tried or invested anytime into proofs and claims type things so far 🤔

On my blog: Real Life in Star Trek, Cause and Effect https://john.colagioia.net/blog/2024/09/12/cause-effect.html #scifi #startrek #closereading

@aelaraji@aelaraji.com Nice write up!

@bender@twtxt.net Does it have to. To my understanding, all you have to do is to add in a claim to your Twtxt feed link into your key, update your profile and post one of These Identity formats to your Twtxt file/Profile…

Give me a couple of minutes, I’ll give it a try myself 😉

@prologic@twtxt.net well…

how would that work exactly?

To my limited knowledge, Keyoxide is an open source project offering different tools for verifying one’s online persona(s). That’s done by either A) creating an Ariande Profile using the web interface, a CLI. or B) Just using your GPG key. Either way, you add in Identity claims to your different profiles, links and whatnot, and finally advertise your profile … Then there is a second set of Mobile/Web clients and CLI your correspondents can use to check your identity claims. I think of them like the front-ends of GPG Keyservers (which keyoxide leverages for verification when you opt for the GPG Key method), where you verify profiles using links, Key IDs and Fingerprints…

Who maintains cox site? Is it centralized or decentralized can be relied upon?

• Maintainers? Definitely not me, but here’s their Git stuff and OpenCollective page …
  
• Both ASP and Keyoxide Webtools can be self-hosted. I don’t see a central authority here… + As mentioned on their FAQ page the whole process can be done manually, so you don’t have to relay on any one/thing if you don’t want to, the whole thing is just another tool for convenience (with a bit of eye candy).
  

Does that mean then that every user is required to have a cox side profile?

Nop. But it looks like a nice option to prove that I’m the same person to whom that may concern if I ever change my Twtxt URL, host/join a yarn pod or if I reach out on other platforms to someone I’ve met in her. Otherwise I’m just happy exchanging GPG keys or confirm the change IRL at a coffee shop or something. 😁

I just received a thought… When you visit a server home page, or any page, why can’t the server sent you a page full of images, asking the human to click on three ants, or four ducks, or two trees, or five cars?
Can an AI machine do such a thing? After a few seconds of human time, the page they wish is downloaded for them. Would this work all you computer experts? (I am getting sick of bots reading my content and stealing my copyright)

@aelaraji@aelaraji.com how would that work exactly? Does that mean then that every user is required to have a cox side profile? Who maintains cox site? Is it centralized or decentralized can be relied upon?

Summer, going too fast. :(

@prologic@twtxt.net can’t one just link to a keyoxide profile with a link to their Twtxt feed for identity or something?

Ford, the company can honestly go fuck themselves! No one ever asked or even thought to themselves:

Gee I wish my car would listen to my in-car conversations and serve me ads.

🤬🤦‍♂️ #Ford #Ads

@slashdot@feeds.twtxt.net i’ll get fucked! The US patent office should ban this immediately.

@xuu@txt.sour.is True 😅 I guess it comes down to our risk appetite and the attack vectors we’re trying to solve for 🤔

@bender@twtxt.net yes I agree.

Fall is in the air now in Minnesota.

@prologic@twtxt.net a signature IS encryption in reverse. If my private key becomes compromised then they can impersonate me. Being able to manage promotion and revocation of keys needed even in a system where its used for just signatures.

@bender@twtxt.net there is a certain simplicity to that. 😅

I was not suggesting to that everyone need to setup a working webfinger endpoint, but that we take the format of nick+(sub)domain as base for generating the hashed together with the message date and content.

If we omit the protocol prefix from the way we do things now will that not solve most of the problems? In the case of gemini://gemini.ctrl-c.club/~nristen/twtxt.txt they also have a working twtxt.txt at https://ctrl-c.club/~nristen/twtxt.txt … damn I just notice the gemini. subdomain.

Okay what about defining a prefers protocol as part of the hash schema? so 1: https , 2: http 3: gemini 4: gopher ?

Ford Seeks Patent For Tech That Listens To Driver Conversations To Serve Ads
Ford is seeking a patent for technology that would allow it to tailor in-car advertising by listening to conversations among vehicle occupants, as well as by analyzing a car’s historical location and other data, according to a patent application published late last month. The Record: “In one example, the controller may moni … ⌘ Read more

@xuu@txt.sour.is 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@txt.sour.is 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@txt.sour.is 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.

Asus X7433RE-IM-A is a 3.5″ Single Board Computer with Intel Atom X7433RE Processor
The X7433RE-IM-A is a 3.5” industrial single board computer designed for industrial applications, featuring the Intel Amston Lake System-on-Chip. It integrates Intel Deep Learning Boost and Advanced Vector Extensions 2 to enhance AI inference and accelerate workloads at the edge, specifically targeting IoT applications. This SBC is available with the x7433RE processor, offering … ⌘ Read more

@xuu@txt.sour.is Thanks for the link. I found a pdf on one of the authors’ home pages: https://ahmadhassandebugs.github.io/assets/pdf/quic_www24.pdf . I wonder how the protocol was evaluated closer to the time it became a standard, and whether anything has changed. I wonder if network speeds have grown faster than CPU speeds since then. The paper says the performance is around the same below around 600 Mbps.

To be fair, I don’t think QUIC was ever expected to be faster for transferring a single stream of data. I think QUIC is supposed to reduce the impact of a dropped packet by making sure it only affects the stream it’s part of. I imagine QUIC still has that advantage, and this paper is showing the other side of a tradeoff.

@movq@www.uninformativ.de Damn! I’m two years late to the discussion 😅 So basically, one could just make a bash script/cron job on the side for pinging non-Http feeds from time to time and the receiving end would get it IF they check their logs.

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

@prologic@twtxt.net Unfortunately it only work if I pull the feed in debug mode jenny -D otherwise, it misses things up if I add that snippet of text to links in my .config/jenny/follow file 😅 Anyway, it was a nice try.

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?

HaloMax Product Line for Long-Range, Low-Power Wireless Solutions
Teledatics’ HaloMax, recently featured on CrowdSupply, is a long-range wireless module designed for applications like smart agriculture, industrial control, and HAM radio. Operating in the sub-1 GHz band, it delivers reliable, power-efficient communication over extended distances with FCC-allowed maximum output power. The HaloMax product lineup offers a range of modules and accessories tailored for long-range

MINIX U8K-ULTRA: 8K UHD Media Hub Powered by Android
MINIX U8K-ULTRA: 8K UHD Media Hub Powered by Android ⌘ Read more

@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! 👌

@movq@www.uninformativ.de @prologic@twtxt.net Hey! I may have found a silly trick to announce my following to people hosting their feeds on the Gemini space using the requested URI itself instead of relaying on the USER Agent 😂. I’ve copied my current feed over to my (to be) Gemlog for testing. And if I do a jenny -D "gemini://gem.aelaraji.com/twtxt.txt?follower=aelaraji@https://aelaraji.com/twtxt.txt" and this happens:

A) As a follower, I get the feed as usual.
B) As the feed owner, I get this in logs:

hostname:1965 - “gemini://gem.aelaraji.com/twtxt.txt?follower=aelaraji@https://aelaraji.com/twtxt.txt” 20 “text/plain;lang=en-US”

You could do the same for Gopher feeds but only if you want to announce yourself by throwing in an error in their logs, then you’ll need a second request to fetch the feed. jenny -D "gopher://gopher.aelaraji.com/twtxt.txt&follower=aelaraji@https:/aelaraji.com/twtxt.txt" gave me this :

gopher.aelaraji.com:70 - [09/Sep/2024:22:08:54 +0000] “GET 0/twtxt.txt&follower=aelaraji@https:/aelaraji.com/twtxt.txt HTTP/1.0” 404 0 “” “Unknown gopher client”

NB: the follower=... string won’t appear in gopher logs after a ? but if I replace it with a + or a & and it works. There will be a missing / after the https:. Probably a client thing.

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

@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

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

@prologic@twtxt.net excellent, thanks!

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

For example:

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

@bender@twtxt.net Yes of course it can 😅 Sorry I missed your question on IRC 😢

#MaradoWeekly #WeeklyRecord Week 37

Image

@jmjl@tilde.green howdy! Sorry for mistaken you with https://blog.nfld.uk/ (jlj), but glad to connect. Cheers!

@mckinley@twtxt.net To answer some of your questions:

Are SSH signatures standardized and are there robust software libraries that can handle them? We’ll need a library in at least Python and Go to provide verified feed support with the currently used clients.

We already have this. Ed25519 libraries exist for all major languages. Aside from using ssh-keygen -Y sign and ssh-keygen -Y verify, you can also use the salty CLI itself (https://git.mills.io/prologic/salty), and I’m sure there are other command-line tools that could be used too.

If we all implemented this, every twt hash would suddenly change and every conversation thread we’ve ever had would at least lose its opening post.

Yes. This would happen, so we’d have to make a decision around this, either a) a cut-off point or b) some way to progressively transition.

@bender@twtxt.net Holy shit that pod is still alive?! 🤔

@sorenpeter@darch.dk WebFinger requires additional setup that whilsts helps to solve the “identity” problem in an “abstract” way, that extra infra that needs to be setup a) isn’t trivial and b) hard to support on “shared hosting”.

Sharing hosting is also the reason why you can’t just use part of a URL really.

On my blog: Developer Diary, Chrysanthemum Day https://john.colagioia.net/blog/2024/09/09/chrysanthemum.html #programming #project #devjournal

how little data is needed for generating the hashes? Instead of the full URL, can we makedo with just the domain (example.net) so we avoid the conflicts with gemini://, https:// and only http:// (like in my own twtxt.txt) or construct something like like a webfinger id nick@domain (also used by mastodon etc.) from the domain and nick if there, else use domain as nick as well

Where all folks?!

@lyse@lyse.isobeef.org this one is hilarious 🤣

@movq@www.uninformativ.de @lyse@lyse.isobeef.org @bender@twtxt.net You Are AWESOME!! Got my playlist for the week!! 🤘😂

@movq@www.uninformativ.de Peobably not and I wouldn’t expect them to either 😅

But in all seriousness I’ve only ever wanted to improve Twtxt without sacrificing its simplicity too much.

@movq@www.uninformativ.de Sorry haha I didn’t mean for it to sound like that 🤣

@mckinley@twtxt.net Hmmm? Care to elaborate? 🤣

@falsifian@www.falsifian.org tag:twtxt.net,2024-09-08:SHA256:23OiSfuPC4zT0lVh1Y+XKh+KjP59brhZfxFHIYZkbZs? :)

@falsifian@www.falsifian.org

Key rotation

Key rotation is useful for security reasons, but I don’t think it’s necessary here because it’s only used for verifying one’s identity. It’s no different (to me) than Nostr or a cryptocurrency. You change your key, you change your identity.

It makes maintaining a feed more complicated.

This is an additional step that you’d have to perform, but I definitely wouldn’t want to require it for compatibility reasons. I don’t see it as any more complicated than computing twt hashes for each post, which already requires you to have a non-trivial client application.

Instead, maybe…allow old urls to be rotated out?

That could absolutely work and might be a better solution than signatures.

HTTPS is supposed to do

My first thought when reading this was to go to my typical response and suggest we use Nostr instead of introducing cryptography to Twtxt. The more I thought about it, however, the more it made sense.

1. It solves the problem elegantly, because the feed can move anywhere and the twt hashes will remain the same.
   
2. It provides proof that a post is made by the same entity as another post.
   
3. It doesn’t break existing clients.
   
4. Everyone already has SSH on their machine, so anyone creating feeds manually could adopt this easily.
   

There are a couple of elephants in the room that we ought to talk about.

1. Are SSH signatures standardized and are there robust software libraries that can handle them? We’ll need a library in at least Python and Go to provide verified feed support with the currently used clients.
   
2. If we all implemented this, every twt hash would suddenly change and every conversation thread we’ve ever had would at least lose its opening post.

🧮 USERS:1 FEEDS:2 TWTS:1087 ARCHIVED:78676 CACHE:2491 FOLLOWERS:17 FOLLOWING:14

@lyse@lyse.isobeef.org This looks like a nice way to do it.

Another thought: if clients can’t agree on the url (for example, if we switch to this new way, but some old clients still do it the old way), that could be mitigated by computing many hashes for each twt: one for every url in the feed. So, if a feed has three URLs, every twt is associated with three hashes when it comes time to put threads together.

A client stills need to choose one url to use for the hash when composing a reply, but this might add some breathing room if there’s a period when clients are doing different things.

(From what I understand of jenny, this would be difficult to implement there since each pseudo-email can only have one msgid to match to the in-reply-to headers. I don’t know about other clients.)

MNT Pocket Reform: Linux-Powered Mini Laptop with Rockchip RK3588 or Amlogic A311D CPU Modules
The MNT Pocket Reform is now officially available for purchase, following the successful delivery of crowdfunded units via Crowd Supply. This 7″ modular mini laptop offers a range of customization options, making it a suitable option for open-source enthusiasts and developers. Users can select from multiple CPU modules, including the A311D (Banana Pi) and t … ⌘ Read more

NanoPi R3S is a $30 Router Board with Dual GbE and FriendlyWrt OS Support
The FriendlyElec NanoPi R3S is an open-source platform designed for IoT applications such as NAS systems and other network-intensive tasks. The device runs on the FriendlyWrt operating system, which is based on OpenWrt. This compact board is powered by the Rockchip RK3566 SoC, featuring a quad-core ARM Cortex-A55 processor clocked at up to 1.8GHz. It

@lyse@lyse.isobeef.org Brilliant idea! 😂 One way ticket to Venus please! 🤘

Six years after my current laptop was purchased, I am going to replace it. The initial cause: one component I cannot find a replacement for - a dilated fan. In the meantime, I also got issues with the keyboard, which a replacement might possibly be found - I didn’t check since the fan issue has no apparent solution.

It is sad that I am being made to replace it before the #RightToRepair European directive was transposed to Portuguese law, but I am still hoping that soon this sort of #ewaste is a thing of the past.

“Fun facts”:

• Laptops account for about 40% of all e-waste generated in the European Union;
  
• Over 90% of a laptop’s environmental impact occurs during the production stage.

LILYGO T3 S3 LR1121: Low-Power LoRa Transceiver for IoT Applications
The LILYGO T3 S3 LR1121 is a development board that supports low-power, long-range wireless communication using LoRa technology. It features the ESP32-S3 System-on-Chip, which offers 2.4 GHz Wi-Fi and Bluetooth Low Energy connectivity, making it suitable for various IoT projects. At the core of the board is the ESP32S3FH4R2 microcontroller, which includes dual-core Xtensa LX7