@quark@ferengi.one It looks like the part about traditional topics has been removed from that page. Here is an old version that mentions it: https://web.archive.org/web/20221211165458/https://dev.twtxt.net/doc/twtsubjectextension.html . Still, I donāt see any description of what is actually allowed between the parentheses. May be worth noting that twtxt.net is displaying the twts with the subject stripped, so some piece of code is recognizing it as a subject (or, at least, something to be removed).
MIT Uses AI Chatbots to Brainwash You
Researchers at MIT & Cornell experiment with using A.I. chatbots to stop people from believing in āConspiracy Theoriesā like āelection fraudā. ā Read more
@sorenpeter@darch.dk I like this idea. Just for fun, Iām using a variant in this twt. (Also because Iām curious how it non-hash subjects appear in jenny and yarn.)
URLs can contain commas so I suggest a different character to separate the url from the date. Is this twt Iāve used space (also after āreplytoā, for symmetry).
I think this solves:
- Changing feed identities: although @mckinley@twtxt.net points out URLs can change, I think this syntax should be okay as long as the feed at that URL can be fetched, and as long as the current canonical URL for the feed lists this one as an alternate.
- editing, if you donāt care about message integrity
- finding the root of a thread, if youāre not following the author
An optional hash could be added if message integrity is desired. (E.g. if you donāt trust the feed author not to make a misleading edit.) Other recent suggestions about how to deal with edits and hashes might be applicable then.
People publishing multiple twts per second should include sub-second precision in their timestamps. As you suggested, the timestamp could just be copied verbatim.
@prologic@twtxt.net I have some ideas:
- Add smartypants rendering, just like Yarn has.
- Add the ability to create individual twtxts, each named after their hash.
- Fix the formatting of the help. :-P
Maybe Iām being a bit too purist/minimalistic here. As I said before (in one of the 1372739 posts on this topic ā or maybe I didnāt even send that twt, I donāt remember š ), I never really liked hashes to begin with. They arenāt super hard to implement but they are kind of against the beauty of the original twtxt ā because you need special client support for them. Itās not something that you could write manually in your
twtxt.txtfile. With @sorenpeter@darch.dkās proposal, though, that would be possible.
Tangentially related, I was a bit disappointed to learn that the twt subject extension is now never used except with hashes. Manually-written subjects sounded so beautifully ad-hoc and organic as a way to disambiguate replies. Maybe Iāll try it some time just for fun.
(#w4chkna) @falsifian@www.falsifian.org You mean the idea of being able to inline
# url =changes in your feed?
Yes, that one. But @lyse@lyse.isobeef.org pointed out suffers a compatibility issue, since currently the first listed url is used for hashing, not the last. Unless your feed is in reverse chronological order. Heh, I guess another metadata field could indicate which version to use.
Or maybe url changes could somehow be combined with the archive feeds extension? Could the url metadata field be local to each archive file, so that to switch to a new url all you need to do is archive everything youāve got and start a new file at the new url?
I donāt think itās that likely my feed url will change.
@movq@www.uninformativ.de I figured it will be something like this, yet, you were able to reply just fine, and I wasnāt. Looking at your twtxt.txt I see this line:
2024-09-16T17:37:14+00:00 (#o6dsrga) @<prologic https://twtxt.net/user/prologic/twtxt.txt>
@<quark https://ferengi.one/twtxt.txt> This is what I get. š¤
Which is using the right hash. Mine, on the other hand, when I replied to the original, old style message (Message-Id: <o6dsrga>), looks like this:
2024-09-16T16:42:27+00:00 (#o) @<prologic https://twtxt.net/user/prologic/twtxt.txt> this was your first twtxt. Cool! :-P
What did you do to make yours work? I simply went to the oldest @prologic@twtxt.netās entry on my Maildir, and replied to it (jenny set the reply-to hash to #o, even though the Message-Id is o6dsrga). Since jenny canāt fetch archived twtxts, how could I go to re-fetch everything? And, most importantly, would re-fetching fix the Message-Id:?
@movq@www.uninformativ.de Iām glad you like it. A mention (@<movq https://www.uninformativ.de/twtxt.txt>) is also long, but we live with it anyway. In a way a replyto: is just a mention of a twt instead of a feed/person. Maybe we chould even model the syntax for replies on mentions: (#<2024-09-17T08:39:18Z https://www.eksempel.dk/twtxt.txt>) ?!
@mckinley@twtxt.net Yes, changing domains is be a problem if you tie your identity to an https url. But I also worry about being stuck with a key I canāt rotate. Whatever gets used, it would be nice to be able to rotate identities. I like @lyse@lyse.isobeef.orgās idea for that.
@movq@www.uninformativ.de I can have more than one Yarn, correct? Like:
"yarn_pods_for_discovery": ["https://twtxt.net", "https://txt.sour.is"],
More:
Subject: The [tag URI scheme](https://en.wikipedia.org/wiki/Tag_URI_scheme) looks interesting. I like that it human read- and writable. And since we already got the timestamp in the twtxt.txt it would be
somewhat trivial to parse. But there are still the issue with what the name/id should be... Maybe it doesn't have to bee that stick? Instead of using `tag:` as the prefix/protocol, it would more it clear
what we are talking about by using `in-reply-to:` (https://indieweb.org/in-reply-to) or `replyto:` similar to `mailto:` 1. `(reply:sorenpeter@darch.dk,2024-09-15T12:06:27Z)' 2.
`(in-reply-to:darch.dk/twtxt.txt,2024-09-15T12:06:27Z)' 2. `(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z)' I know it's longer that 7-11 characters, but it's self-explaining when looking at the
twtxt.txt in the raw, and the cases above can all be caught with this regex: `\([\w-]*reply[\w-]*\:` Is this something that would work?
Subject: The [tag URI scheme](https://en.wikipedia.org/wiki/Tag_URI_scheme) looks interesting. I like that it human read- and writable. And since we already got the timestamp in the twtxt.txt it would be
somewhat trivial to parse. But there are still the issue with what the name/id should be... Maybe it doesn't have to bee that stick? Instead of using `tag:` as the prefix/protocol, it would more it clear
what we are talking about by using `in-reply-to:` (https://indieweb.org/in-reply-to) or `replyto:` similar to `mailto:` 1. `(reply:sorenpeter@darch.dk,2024-09-15T12:06:27Z)` 2.
`(in-reply-to:darch.dk/twtxt.txt,2024-09-15T12:06:27Z)` 3. `(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z)` I know it's longer that 7-11 characters, but it's self-explaining when looking at the
twtxt.txt in the raw, and the cases above can all be caught with this regex: `\([\w-]*reply[\w-]*\:` Is this something that would work?
Notice the difference? Soren edited, and broke everything.
@mckinley@twtxt.net Thanks for the feedback.
- Yeah I agrees that nick sound not be part of syntax. Any valid URL to a twtxt.txt-file should be enough and is more clear, so it is not confused with a email (one of the the issues with webfinger and fedivese handles)
- I think any valid URL would work, since we are not bound to look for exact matches. Accepting both http and https as well as a gemni and gophe could all work as long as the path to the twtxt.txt is the same.
- My idea is that you quote the timestamp as it is in the original twtxt.txt that you are referring to, so you can do it by simply copy/pasting. Also what are the change that the same human will make two different posts within the same second?!
Regarding the whole cryptographic keys for identity, to me it seems like an unnecessary layer of complexity. If you move to a new house or city you tell people that you moved - you can do the same in a twtxt.txt. Just post something like āI move to this new URL, please follow me there!ā I did that with my feeds at least twice, and you guys still seem to read my posts:)
The tag URI scheme looks interesting. I like that it human read- and writable. And since we already got the timestamp in the twtxt.txt it would be somewhat trivial to parse. But there are still the issue with what the name/id should be⦠Maybe it doesnāt have to bee that stick?
Instead of using tag: as the prefix/protocol, it would more it clear what we are talking about by using in-reply-to: (https://indieweb.org/in-reply-to) or replyto: similar to mailto:
(reply:sorenpeter@darch.dk,2024-09-15T12:06:27Z)
(in-reply-to:darch.dk/twtxt.txt,2024-09-15T12:06:27Z)
(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z)
I know itās longer that 7-11 characters, but itās self-explaining when looking at the twtxt.txt in the raw, and the cases above can all be caught with this regex: \([\w-]*reply[\w-]*\:
Is this something that would work?
Thank you @aelaraji@aelaraji.com, Iām glad you like it. I use PHP because itās everywhere on cheap hosting and no need for the user to log into a terminal to setup it up. Timeline is not mean to be use locally. For that I think something like twtxt2html is a better fit. (and happy to see you using simple.css on you new log page;)
Milk-V DuoModule Eval Board with RISC-V Core, 8051 Core, and Linux Support
The Milk-V DuoModule 01 Evaluation Board offers a versatile platform for evaluating the Duo Module 01, featuring Wi-Fi 6, Bluetooth 5.4, and eMMC storage. It enables developers and makers to prototype solutions using the SG2000 SoC, with open-source documentation to streamline development. Like the Milk-V Duo S and Oz64, this board features the SG2000 SoC, [ā¦] ā Read more
ODROID-M2 Leverages RK3588S2 SoC and Supports LPDDR5 Memory
The ODROID-M2 builds on the success of the Hardkernel ODROID-M1 series, offering enhanced computing power for industrial embedded systems. Powered by the RK3588S2 SoC, the ODROID-M2 provides significant improvements in both processing power and memory performance. Like the Radxa 5C and Lite models, the ODROID-M2 is equipped with the RK3588S2. This system features an octa-core [ā¦] ā Read more
KubeCon + CloudNativeCon North America 2024 co-located event deep dive: Observability Day
Co-chairs: Eduardo Silva, Chronosphere, Austin Parker, Honeycomb, Anna Kapuscinska, Isovalent at CiscoNovember 12, 2024Salt Lake City, Utah Observability is a journey, and in a diverse ecosystem like ours, itās easy to get confused or use the wrong tools⦠ā Read more
Key rotation is a very important feature in a system like this.
Snikket: Snikket Server - September 2024 release
We hope youāve been having a good summer (at least if youāre up here in the
northern hemisphere). Today weāre back with a new release of the self-hosted
Snikket server software.
This software is whatās at the core of the Snikket project - a self-hostable
āpersonal messaging server in a boxā. If you wish for something like
Messenger, WhatsApp or Signal, but not using their servers, Snikket is for
you. Once deployed, you can create invitation links for family, f ⦠ā Read more
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: ...
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 [ā¦] ā Read more
The Self-Destruction of Open Source Software
Is it on purpose? It sure seems like itās on purpose. ā Read more
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
@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.)
@movq@www.uninformativ.de Another idea: just hash the feed url and time, without the message content. And donāt twt more than once per second.
Maybe you could even just use the time, and rely on @-mentions to disambiguate. Not sure how that would work out.
Though I kind of like the idea of twts being immutable. At least, itās clear which version of a twt youāre replying to (assuming nobody is engineering hash collisions).
@prologic@twtxt.net Some criticisms and a possible alternative direction:
Key rotation. Iām not a security person, but my understanding is that itās good to be able to give keys an expiry date and replace them with new ones periodically.
It makes maintaining a feed more complicated. Now instead of just needing to put a file on a web server (and scan the logs for user agents) I also need to do this. What brought me to twtxt was its radical simplicity.
Instead, maybe we should think about a way to allow old urls to be rotated out? Like, my metadata could somehow say that X used to be my primary URL, but going forward from date D onward my primary url is Y. (Or, if you really want to use public key cryptography, maybe something similar could be used for key rotation there.)
Itās nice that your scheme would add a way to verify the twts you download, but https is supposed to do that anyway. If you donāt trust https to do that (maybe you donāt like relying on root CAs?) then maybe your preferred solution should be reflected by your primary feed url. E.g. if you prefer the security offered by IPFS, then maybe an IPNS url would do the trick. The fact that feed locations are URLs gives some flexibility. (But then rotation is still an issue, if I understand ipns right.)
@movq@www.uninformativ.de @prologic@twtxt.net Another option would be: when you edit a twt, prefix the new one with (#[old hash]) and some indication that itās an edited version of the original tweet with that hash. E.g. if the hash used to be abcd123, the new version should start ā(#abcd123) (redit)ā.
What I like about this is that clients that donāt know this convention will still stick it in the same thread. And I feel itās in the spirit of the old pre-hash (subject) convention, though thatās before my time.
I guess it may not work when the edited twt itself is a reply, and there are replies to it. Maybe that could be solved by letting twts have more than one (subject) prefix.
But the great thing about the current system is that nobody can spoof message IDs.
I donāt think twtxt hashes are long enough to prevent spoofing.
@bender@twtxt.net So far Iāve been following feeds fairly liberally. Iāll check to see if we have anything in common and lean toward following, just because this is new to me and it feels like a small community. But Iām still figuring out what I want. Later Iāll probably either trim my follower list or come up with some way to prioritize the feeds Iām more interested in.
@lyse@lyse.isobeef.org 31°C here, feels like 33°C, with a lovely 75% of humidity. It has been raining, on and off (to make matter ābetterā) the whole day until now. No horses here, but if you go outside you will smell the same smell of farm animals (like goats, or pigs). Thatās because two or three kilometres from here there are private farms, and when the wind blows in such way, well, we are reminded of their existence.
I havenāt left the house, so it feels well under air conditioning. In two more hours I will call it quits from the work day, and will have to dash to the grocery to get supplies for tonightās meal (arroz con gandules). I will let you know how it truly feels out there then. :-D
For those swollen fingers, nothing better than a mildly cold shower! Oh, and paws off the keyboard! :-P
@dbucklin@www.davebucklin.com very nice, thank you for sharing! I like that kind of retailers too, so those are on my list now. š
Erlang Solutions: Meet the team: Joanna Wrona
In this edition of our āMeet the Teamā series, weād like to introduce you to Joanna Wrona, Business Unit Leader for the Kraków office at Erlang Solutions.
She discusses her role at ESL and her passion for empowering her team. She also gives us a glimpse into life in beautiful Kraków and what makes her journey so fulfilling.
About Joanna**What is your ⦠ā Read more
@prologic@twtxt.net I guess I thought they were search engines. Anyway, the registry API looks like a decent one for searching for tweets. Could/should yarn.social pods implement the same API?
@prologic@twtxt.net How does yarn.socialās API fix the problem of centralization? I still need to know whose API to use.
Say I see a twt beginning (#hash) and I want to look up the start of the thread. Is the idea that if that twt is hosted by a a yarn.social pod, it is likely to know the thread start, so I should query that particular pod for the hash? But what if no yarn.social pods are involved?
The community seems small enough that a registry server should be able to keep up, and I can have a couple of others as backups. Or I could crawl the list of feeds followed by whoever emitted the twt that prompted my query.
I have successfully used registry servers a little bit, e.g. to find a feed that mentioned a tag I was interested in. Was even thinking of making my own, if I get bored of my too many other projects :-)
iPadOS 18 is Compatible with These iPads
iPadOS 18 for iPad includes some exciting new features for iPad users, from more interface customization options like Dark Mode icons and widgets, color hued icons and widgets, a customizable Control Center, the debut of a Calculator app for iPad, Passwords app, a Photos redesign, improvements to Notes app, new features in Safari like Distraction ⦠Read More ā Read more
Kubernetes turns 10: a ditty dedicated to a decade of container orchestration
Member post originally published on Fairwindsā blog by Stevie Caldwell Itās hard to believe, but Kubernetes, our favorite container orchestration tool,Ā turned tenĀ this year! It feels like just yesterday when it was just an internal project at Google spinning⦠ā Read more
** September summer **
I finished reading Robin Sloanās Moonbound today. It was fun, and light. The blurb likens it to Narnia, and, while a bold claim, I think that was a correct assertion, but more about the intended audience than the bookās subject matter. If a sequel is ever written Iād most certainly give it a look. It seems like a great gift book for a kid between like 8 and 15ā¦or you know, perhaps, anyone who likes fun stories that arenāt scared of bein ⦠ā Read more
As a rule of thumb, I only want to own or use computing devices that are not powerful enough to run a large language model. I like things simple and small.
@quark@ferengi.one Check out this thread if you havenāt already: https://mastodon.social/@sundogplanets/112464533481477428
I think we already know Itās likely to be a disaster.
@mckinley@twtxt.net agevault uses age, allegedly very secure (aiming to replace pgp/gpg). Comparing it with gocryptfs, from the user perspective, agevault seems simpler, though CLI exclusive. As the repository states, āLike age, it features no config options, allowing for a straightforward secure flowā. It would also run in all major OS platforms out of the box.
But agevault is also very new. Though age has been around for a while now, I donāt see an āauditedā link (neither on agevault, nor age).
@New_scientist@feeds.twtxt.net Itās great that US regulators have approved launching 40,000 satellites with a 5-year lifespan before we had this kind of information about whatās likely to happen when they start falling out of orbit at a rate of several per hour.
Erlang Solutions: 5 Ways MongooseIM Provides Scalable and Future-Proof Messaging
CTOs with instant messaging requirements are facing a challenge. Whether they are looking to improve an existing instant messaging system or implement one for the first time, they need a messaging solution that can scale to meet growing demands. It must also integrate with existing systems and remain future-proof against technological changes. It sounds like a lot to ask for, but traditi ⦠ā Read more
@prologic@twtxt.net My pod, which is running the same commit you are, does not return an error like that. It returns the same HTML it always has. Try it. I nuked my cache before restarting.
Edit: Oh wait, the plot thickens. I do get an error if I use curl or if I use a web browser that isnāt logged in. Thatās good!
yarnd that's been around for awhile and is still present in the current version I'm running that lets a person hit a constructed URL like
A stopgap setting that would let me stop all calls to /external matching a particular pattern (like this damn lovetocode999 nick) would do the job. Given the potential for abuse of that endpoint, having more moderation control over what it can do is probably a good idea.
yarnd that's been around for awhile and is still present in the current version I'm running that lets a person hit a constructed URL like
@prologic@twtxt.net This does not seem to fix the problem for me, or Iāve done something wrong. I did the following:
- Pull the latest version from
git(I have commit7ad848, same as ontwtxt.netI believe).
make buildandmake install
- Restart
yarnd
- Refresh cache in Poderator Settings
Yet I still see these bogus /external things on my pod when I hit URLs like the one I sent you recently. When I hit such a URL with curl I think itās giving an error? But in a web browser, the (buggy) response is the same as it was before I updated.
So, this problem is not fixed for me.
yarnd that's been around for awhile and is still present in the current version I'm running that lets a person hit a constructed URL like
@prologic@twtxt.net I believe you are not seeing the problem I am describing.
Hit this URL in your web browser:
https://twtxt.net/external?nick=lovetocode999&uri=https://socialmphl.com/story19510368/doujin
Thatās your pod. I assume you donāt have a user named lovetocode999 on your pod. Yet that URL returns HTTP status 200, and generates HTML, complete with a link to https://socialmphl.com/story19510368/doujin, which is not a twtxt feed (thatās where the twtxt.txt link goes if you click it). That link could be to anything, including porn, criminal stuff, etc, and it will appear to be coming from your twtxt.net domain.
What I am saying is that this is a bug. If there is no user lovetocode999 on the pod, hitting this URL should not return HTTP 200 status, and it should definitely not be generating valid HTML with links in it.
Edit: Oops, I misunderstood the purpose of this /external endpoint. Still, since the uri is not a yarn pod, let alone one with a user named lovetocode999 on it, I stand by the belief that URLs like this should be be generating valid HTML with links to unknown sites. Shouldnāt it be possible to construct a valid target URL from the nick and uri instead of using the podās /external endpoint?
Kubestronaut in Orbit: Fangel Colón
Get to know Fangel This weekās Kubestronaut in Orbit, Fangel Emilio Colón Navarro, lives in the Dominican Republic and is an SRE at Banco BHD. Heās been working with CNCF technologies since 2020. If youād like to be⦠ā Read more
vim cursor at the end of the first line on replies, and forks. I have tried adding to this to jenny's configuration:
@movq@www.uninformativ.de hmm, I guess I could do that too. I have startinsert set on my .vimrc, so I will either have to take it out, or exit insert, $, then insert again. I think the way you do it would be the way to go.
I tried setting VISUAL to be something like vim -c 'star!', which does the same thing, but no dice. :-/
Building a translation agent on LlamaEdge
Member post originally published on Second Stateās blog Prof. Andrew NgāsĀ agentic translationĀ is a great demonstration on how to coordinate multiple LLM āagentsā to work on a single task. It allows multiple smaller LLMs (like Llama-3 or Gemma-2) to⦠ā Read more
There is a bug in yarnd thatās been around for awhile and is still present in the current version Iām running that lets a person hit a constructed URL like
YOUR_POD/external?nick=lovetocode999&uri=https://socialmphl.com/story19510368/doujin
and see a legitimate-looking page on YOUR_POD, with an HTTP code 200 (success). From that fake page you can even follow an external feed. Try it yourself, replacing āYOUR_PODā with the URL of any yarnd pod you know. Try following the feed.
I think URLs like this should return errors. They should not render HTML, nor produce legitimate-looking pages. This mechanism is ripe for DDoS attacks. My pod gets roughly 70,000 hits per day to URLs like this. Many are porn or other types of content I do not want. At this point, if itās not fixed soon I am going to have to shut down my pod. @prologic@twtxt.net please have a look.