@aelaraji@aelaraji.com Haha don’t ask me 🤣 I don’t do PHP 😆

@arne@uplegger.eu Hahaha, vor Dekaden hab ich auch mal einen „XML“-„Parser“ selbst gebaut. Der wollte dann pro Zeile entweder einen öffnenden oder einen schließenden Tag oder aber einen Wert haben. :-O Ganz übel, aber für den damaligen Anwendungsfall hat’s gelangt. War halt bloß kein XML. :-D

Was konkret war dann das Problem von dem zu sauberen XML in Deinem Fall? Und schön zu hören, dass Du das Gerät vor dem vorzeitigen Elektroschrotttod bewahrt bekommen hast. :-)

Zum Abschluss noch ne ganz doofe Frage, ganz offensichtlich hab ich von Radios keinen blassen Schimmer. Wieso muss denn das Ding überhaupt mit XML rumfuhrwerken? O_o

LECK MICH FETT!
Das Küchenradio (Sagem - My Dual Radio 700) gibt wieder Töne von sich! Der XML-Parser von dem Ding ist sowas von hinüber. Die “Fertiglösungen” YCast und YTuner haben ein zu ordentliches XML erstellt. Per Trial and Error habe ich dann die Formatierung gefunden, die die olle Kiste braucht. 🥳

@lyse@lyse.isobeef.org i trusted all pods yesterday and now when i pull it up they are all untrusted.

Image

@xuu@txt.sour.is The Pod.LastSeen and Pod.LastUpdated fields are only ever updated in the Cache.DetectPodFromUserAgent(…) function as far as I can tell. This function is called in Cache.DetectClientFromRequest(…) and Cache.DetectClientFromResponse(…).

Cache.DetectClientFromRequest(…) is only invoked when the twtxt.txt is requested and looks at the User-Agent HTTP request header.

Cache.DetectClientFromResponse(…) is only called in Cache.FetchFeeds(…) and looks at the Powered-By HTTP response header. This header would be set in twtxt.txt HTTP responses from yarnd. A bunch of places invoke Cache.FetchFeeds(…), including a periodic job (UpdateFeedsJob.Run()). Maybe something is iffy around these locations.

@movq@www.uninformativ.de It’s an old, cheap Optus without any model information on it. It was maybe 180DM or so in a discounter 25, 30 years ago. Its main job is to collect dust, can’t even remember its last use. That must have been easily 15 years ago I reckon. Thus, absolutely no surprise. Maybe I’ll just take it apart and see what I can see as the week progresses.

@lyse@lyse.isobeef.org Oh no. 🥴 What kind of telescope have you got?

I’m rather frozen after half an hour looking at Venus and Saturn through the telescope outside. I couldn’t see any rings around Saturn. Disappointing. It also appeared rather dark. The very bright Venus on the other hand told me that there is something growing inside the scope. :-( Or maybe there is dust.

An all time favorite. // Amorphis - Drifting Memories // https://www.youtube.com/watch?v=WoY4oJkpBEs #NowPlaying

@xuu@txt.sour.is I added some logging when a “dead” peer is removed as I suspect this to be a hot candidate for all the trouble. https://git.mills.io/yarnsocial/yarn/commit/21538951f9dc71b9366db6dbb784a8078096a4c8 Does this yield anything?

@aelaraji@aelaraji.com @prologic@twtxt.net Hmmm!

It’s nice to see we’re all largely thinking along the same lines. e.g: Salty.im 😅

@eapl.me@eapl.me Yeah this is true. Previously RSA and AES were more common. These days Salsa and Chacha and Curve are fairly prevalent. For example all the Wireguard stuff uses Curve25519 / Ed25519 crypto. Signal uses very similar crypto too, but with some very nice double ratcheting 3DH.

@eapl.me@eapl.me I -think we’ve gotten use to it somewhat 🤣

@doesnm@doesnm.p.psf.lt whilst technically true, expensive and unnecessary.

@johanbove@johanbove.info Easier said than done. Couldn’t believe my eyes this morning.

It is not possible to remove it, otherwise you do not know that the message is for you. With that information you can’t decrypt.

@doesnm@doesnm.p.psf.lt I always do 👌

Keep breathing and stay cool.

👋👋 Reminders that this weekend our monthly Yarn.social online meetup. Who’s coming? 🤔 Some possible topics:

• Direct Messaging for Twtxt
  
• @prologic@twtxt.net ’s new EdgeGuard services 🤣
  
• What’s the weather like? 👍
  

Details:

• When: 25th Jan 2025 at 12:00PM UTC (midday)
  
• Where: https://meet.mills.io/call/Yarn.social

@eapl.me@eapl.me@eapl.me@eapl.me But we’re actively discussing on Twtxt 🤣

@eapl.me@eapl.me@eapl.me@eapl.me Agree with the base64 encoding 👌

@eapl.me@eapl.me@eapl.me@eapl.me actually it is easy 🤣 It’s now the standard for SSH keys 😆

@aelaraji@aelaraji.com Hmmm? 🤔

@xuu@txt.sour.is Is this because there’s a bug in persisting trusted peers? 🤔

@lyse@lyse.isobeef.org This is a good point.

@doesnm@doesnm.p.psf.lt That’s actually not true, because you’d have to know the target you’re interested in, in the first place. Inboxes in Salty.IM are deliberately shahed for this reason. So whilst you may know your own inbox address, etc, I (as an arbitrary bad actor) wouldn’t easily be able to guess (let alone brute force) my way to another inbox address of an interested party.

It’s ok for most encrypted protocols (In salty you can fetch other messages but can’t decrypt). Btw i think recipient can be removed so if someone seen message they tried to decypt, if can’t - its not message to you

hmmm? 🤔

I remember starting that one.. it was a bit gratuitous for me to get past the first few episodes.

and yes.. these all come with satisfying endings across multiple seasons.

my goto’s are the Expanse, the Magicians, XFiles, House, Umbrella Academy, Orphan Black, 12 Monkeys, the star treks (DS9 especially)

i have probably watched through them a half dozen times each. some more :D

It seems related to us poor single user pods not getting the trust to share twts.. which it seems to still untrust on restart for me.

@movq@www.uninformativ.de ^^

@movq, @prologic@twtxt.net when navigating to a Yarn. If the head twt is missing then the whole thread is not accessible. It only returns an error. so i have no way to view any of the replies within the thread other than the end twt.

@xuu@txt.sour.is Can you elaborate in textual form for the poor vision impaired developer 🤣 🙏

Just threw this RSS feed into Newsboat. The titles suck, but I hope the content makes up for it. :-)

@movq@www.uninformativ.de Speaking of fog, a workmate showed me his view out of the window today and you couldn’t even see a hundred meters. Looked really nice! :-) We actually had a little bit of sun over here.

@movq@www.uninformativ.de Woah, that sun from satellite SDO is fucking sick! https://social.bund.de/system/media_attachments/files/113/859/065/836/106/300/original/95b43f7a0086476d.jpeg

@xuu@txt.sour.is What’s going on here? Are you doing anything or does it jump to that error page randomly?

@lyse@lyse.isobeef.org Ahh, that good old orange light. 😍 Yeah, everything’s foggy here as well.

I haven’t read the entire specification, but I think there is a fundamental design problem. Why would someone put an encrypted message on a public feed that is completely useless to everybody other than the one recipient? This doesn’t make sense to me. It of course depends on the threat model, but wouldn’t one also want to minimize the publicly visible metadata (who is communicating with whom and when) when privately messaging? I feel there are better ways to accomplish this. Sorry, if I miss the obvious use case, please let me know. :-)

Clouds are hiding the planets right now, but the sky was slightly on fire before: https://lyse.isobeef.org/abendhimmel-2025-01-20/

Image

This UX can be very frustrating.

Video

another one would be to allow changing public keys over time (as it may be a good practice [0]). A syntax like the following could help to know what public key you used to encrypt the message, and which private key the client should use to decrypt it:

!<nick url> <encrypted_message> <public_key_hash_7_chars>

Also I’d remove support for storing the message as hex, only allowing base64 (more compact, aiming for a minimalistic spec, etc.)

[0] https://www.brandonchecketts.com/archives/its-2023-you-should-be-using-an-ed25519-ssh-key-and-other-current-best-practices

my first thought is that encrypting messages with Elliptic keys is not as easy as with RSA, although I tried doing something similar a few months ago with ECIES
https://github.com/eapl-gemugami/owl/blob/main/src/app/controller/ecies_demo.php

interesting idea. I’m not personally interested on having DM conversations on twtxt (for now), although I see the community could be interested in.

I’d suggest to enable the Discussion section in your Github repo to receive comments, as we did for timeline https://github.com/sorenpeter/timeline/discussions

@eldersnake@we.loveprivacy.club @arne@uplegger.eu Don’t let your telescopes rot! 😃

@lyse@lyse.isobeef.org They say, 18:48 today is the next time slot: https://social.bund.de/@dlr_next/113859521382441187

@andros@twtxt.andros.dev 🤩😍

It would also be great if you put up a PR against twtxt.dev 🙏