@movq@www.uninformativ.de how do you set your clock to use a specific time signal radio station? I have one wall clock in my office, it works great, but no way to set that.

German government comes out against Chat Control
https://xcancel.com/paddi_hansen/status/1975595307800142205

great! no chat control, for now!

DCF77, our time signal radio station, is a great public service. I really love that. It’s just a signal that anybody can pick up, no subscription, no tracking, no nothing. Much like GPS/GNSS. 💚

This makes me happy. Radio controlled clocks perfectly in sync. ⌚🥳

https://movq.de/v/6b1847a056/VID_20251007_181904.mp4.mp4

@lyse@lyse.isobeef.org As the kids on imgur say: I always updoot birbs 👍

So green, so many mushrooms. 🤯

@prologic@twtxt.net Oh, I will certainly check this out! Thanks for the tip, mate! <3

@lyse@lyse.isobeef.org Cool! 😎 You might be interested in my own learnings and toying around with building my own container engine / tooling (whatever you wanna call it) box. I had to learn a bunch of this stuff too 😅 Control Groups, Namespaces, Process Isolation, etc.

My open letter, to the European Commission digital markets act team:

Hello,

I am joining other developers, concerned about Googles new plan, to approve every app and effectively destroy most of the competing 3rd party stores this way. The biggest one of these alternative stores, most known for their focus on user and developer privacy, already states, this would make it impossible for them to operate: https://f-droid.org/cs/2025/09/29/google-developer-registration-decree.html
Even communities like the XDA forum, where new developers are often introduced to the world of Android development, would likely be strongly impacted, as making, publishing and installing Android apps is made less accessible.

I am not just writing on their behalf, I run a small website myself (https://thecanine.ueuo.com/), that both provides legal modifications, for some android apps - for example adding an amoled dark theme, to the most popular XMPP chat client for Android, or increasing one of Androids keyboard apps height. This all comes after Googles previous changes to the Android operating system, that prevent users from installing old apps (old to Google, can mean only a couple of months, without an update - https://developer.android.com/google/play/requirements/target-sdk and the target version gets increased every year). I rely on apps developed by a single developer, even for things like making the pixel art presented on my website and sideloading as a way to make these apps work, before developers can catch up to Google’s new requirements - if Google is allowed to slowly kill these options, us digital artists will soon lose the tools we need to create digital art.

@prologic@twtxt.net i’m guessing then a HEAD request is sent every 5m, and then the feed is fetched if the headers are different?

also what would be the cases where a feed would be fetched more than every five minutes? :o

@lyse@lyse.isobeef.org Great job!

I suggested it because I did it in the past, but never used it on bigger works.

In my case I did it exclusively on really small projects and used a thin rubber head hammer to prevent deforming the metal.

@itsericwoodward@itsericwoodward.com @bender@twtxt.net this is vaguely concerning…does yarn refresh feeds every minute or two? or is there some special “notify twtxt.net to refresh my feed” that i don’t know about

Got a ubuntu vm installed, with tailscale, and it works with a public url, so next is to migrate a service and point my domain to it

The VPS provider I use is shutting down, so I have to move things.
I will try and move my yarn instance over to my own hardware, and use tailscale to point to it.
Got some other services to move as well, but I’ll start with this first.

Big storm coming in tonight, fingers crossed!

@lyse@lyse.isobeef.org I think you should be able to find some even in general stores in the hardware section.

Hello again everyone! A little update on my twtxt client.

I think it’s finally shaping a bit better now, but… ☝️

As I’m trying to put all the parts together, I decided to build multiple parallel UIs, to ensure I don’t accidentally create a structure that is more rigid than planned.

I already decided on a UI that I would want to use for myself, it would be inspired by moshidon, misskey and some other “social feeds” mock-ups I found on dribbble.

I also plan on building a raw HTML version (for anyone wanting to do a full DIY client).

I would love to get any suggestions of what you would like to see (and possibly use) as a client, by sharing a link, app/website name or even a sketch made by you on paper.

I think I’ll pick a third and maybe a fourth design to build together with the two already mentioned.

For reference, the screens I think of providing are (some might be optional or conditionally/manually hidable):

• Global / personal timeline screen
  
• Profile screen (with timeline)
  
• Thread screen
  
• Notifications screen or popup (both valid)
  
• DM list & chat screens (still planning, might come later)
  
• Settings screen (it’ll probably be a hard coded form, but better mention it)
  
• Publish / edit post screen or popup (still analysing some use cases, as some “engines” might not have direct publishing support)
  

I also plan on adding two optional metadata fields:

• display_name: To show a human readable alternative for a nick, it fallback to nick if not defined
  
• banner: Using the same format as avatar but the image expected is wider, inspired by other socials around
  

I also plan on supporting any metadata provided, including a dynamically parsable regex rule format for those extra fields, this should allow anyone to build new clients that don’t limit themselves to just the social aspect of twtxt, hoping to see unique ways of using twtxt! 🤞

Spooky season is upon us, so I can take a month break, from being a paper clip.

@alexonit@twtxt.alessandrocutolo.it prologic has me sold on the idea of hashv2 being served alongside a text fragment, eg. (#abcdefghijkl https://example.com/tw.txt#:~:text=2025-10-01T10:28:00Z), because it can be simply hacked in to clients currently on hashv1 and provides an off-ramp to location-based addressing (though i still think the format should be changed to smth like #<abc... http://example.com/...> so it’s cleaner once we finally drop hashes)

is the first url metadata field unequivocally treated as the canon feed url when calculating hashes, or are they ignored if they’re not at least proper urls? do you just tolerate it if they’re impersonating someone else’s feed, or pointing to something that isn’t even a feed at all?

and if the first url metadata field changes, should it be logged with a time so we can still calculate hashes for old posts? or should it never be updated? (in the case of a pod, where the end user has no choice in how such events are treated) or do we redirect all the old hashes to the new ones (probably this, since it would be helpful for edits too)

I always wanted to build a terrarium, but after cleaning my keyboard today, I think I already have one…

Our Husky Nanook has been living outside 24/7 since summer (except for 2-3 nights). Yesterday I finished his new insulated house, made it with my stepdad. So now Nanook is ready to spend the whole year outside.

Image

@lyse@lyse.isobeef.org I can suggest you a trick to do a “cold” welding.

Using a copper wire or a similarly malleable material, pass it through a drilled hole, hammer it on one end until flat, then do the same on the other side.

It does the same job of a rivet but it’s flatter and look nicer on both sides, it’s of course weaker but still strong enough for small objects.

It’s sometimes used to reduce risk of deformities due to heat in hand-crafted jewelry and to reduce costs of small tools.

Hi everyone, here’s a little introduction of my twtxt client (still WIP).

The client I’m developing is a single tenant project that runs entirely in the browser (it might use an optional backend).

It’s entirely based on native web-components and vanilla JS, it is designed to act closer to a toolkit than a full-fledged client, allowing users to “DIY” their own interface with pure html or plain javascript functions.

Users can also build their own engines by including a global javascript object that implement the defined internal API (TBD).

I’m planning to build a system that is easy enough to build and use with any skill level, using only pure html (with a homebrew minimal template engine) or via plain JS (I’ll be also providing some pre-made templates too).

Everything can be self-hosted on any static hosting provider, this allows to spread twtxt within communities like Neocities and similarly hosted websites (basically any Indieweb/Smallweb/Digital garden website and any of the common GitHub/Lab/Berg/lify Pages).

It will be probably named something like TxtCraft or craf.txt but I’m not really sure yet… 🤔 (Maybe some suggestions could help)

I’m still in the experimental phase, so there’s no decent source-code to share yet, but it will soon enough!

@lyse@lyse.isobeef.org Beautiful handwork, how did you seal the corners? I don’t see and hole or anything.

BTW, That Sheet Metal Dude is something else himself, skilled enough to teach others, can work properly with self-imposed contraints, care about safety and is humble enough to be wiling to learn from others, a true craftman worthy of respect.

That’s what I’m using right now, while my own client is still in the making.

A simple bash script to write a post in a mktemp file then clean it with regex.
I don’t even bother to hash the replies, I just open https://twtxt.net and copy the hash by hand since I’m checking the new posts from there anyway (temporarily, as I might end up DoS-ing everyone’s feed in my client right now).

plus, if hashv2 was implemented in combination with text fragments the way you proposed that would solve both scripting and human readability woes!!

…though, the presence of the text fragments then makes reversing the replied-to twt (and therefore its hash) trivial, which could allow clients to tolerate the omission of the hash — and while it would be ‘non-standard’ this would be the best of both worlds; potential to tolerate (or pave a glacial path toward? :o) human writable replies whilst keeping a unique id for twts that is universal across all pods

@prologic@twtxt.net to clarify: i meant the ability to parse feeds using unix command line utilities, as a principal of twtxtv1’s design. im not sure how feasible it is to build a simple feed reader out of common scripting utilities when hashing is in play, and;

i concede, it does make a lot of sense to fix up the hashing spec rather than completely supplant it at this point, just thinking about what the rewrite would be like is dreadful in and of itself x.x

@prologic@twtxt.net the simplest thing to do is to completely forgo hashing anything because we are communicating using plain text files right now :3 while i agree hashes are incredibly helpful in the backend im not sure it has a place outside of it, it basically eliminates two core design principals of twtxt (human readability and integrating well with unix command line utilities) and makes new clients more difficult to build than it should be

@itsericwoodward@itsericwoodward.com I used the dates as is for indexing them as string, the ISO format allows for free auto sorting.

@bender@twtxt.net What?! In my country you have to pay 100€ every 10 years of which about 75% are just taxes…

@movq@www.uninformativ.de I tried making an ascii scribble of penguin waving back at you but I gave up halfway through my first try xD … HI! 👋

Thanks @bender@twtxt.net it’s been a long time indeed but, I was here the whole time. Just silent. I just didn’t have much meaningful/worth twting about … /ME flips a bird to life

exit

Yey! I Think we’re back on track. All I was missing was #twtxt2html and a couple of symlincs into ~/bin

Nothing serious! just a sanity check Twt x) ...

anyway sup friends i hosted an IRC server

whyyyyy is my discover page only showing 7 twts!!!

@prologic@twtxt.net thanks, I already follow @important_dev_news@n8n.andros.dev too.

BTW, the feed on https://feeds.twtxt.net/ seem down? It says it’s in maintenance.

long month

@zvava@twtxt.net @lyse@lyse.isobeef.org I also think a location based reference might be better.

A thread is a single post of a single feed as a root, but the hash has the drawback of not referencing the source, in a distributed network like twtxt it might leave some people out of the whole conversation.

I suggest a simpler format, something like: (#<TIMESTAMP URL>)

This solves three issues:

• Easier referencing: no need to generate a hash, just copy the timestamp and url, it’s also simpler to implement in a client without the rish of collisions when putting things together
  
• Fetchable source: you can find the source within the reference and construct the thread from there
  
• Allow editing: If a post is modified the hash becomes invalid since it depends on [ timestamp, url, content ]

Hello everyone! 👋

After a long while away, I’m back on twtxt with this new feed.

Some of you might remember me as justamoment@twtxt.net, that was a test account I made for trying things out, but I ended up keeping it more than planned.

I also tried other social platforms in search of a place that felt right for me.

In the end twtxt was the one that ticked all of my boxes:

• Slow social: it act more like a feed reader and I really appreciate that there’s no flood of content that I can’t keep up with.
  
• No server needed: I absolutely love to have total control over my content, I tend to avoid having moving parts that might break, plus you can put your feed under version control and it’s all backed up.
  
• Ownership: I can put my feed anywhere I want and nobody can decide if I can access it or not.
  
• For hackers: a single .txt file allows me to join a community, how cool is that!
  

This is why I decided to build my own twtxt client, one that allows you to decide how the feed is presented on your “instance”.

It’s still in the making but I’ll try to share a bit of it once I defined how things should work.

Coincidentally, I discovered that @itsericwoodward@itsericwoodward.com and @zvava@twtxt.net were also building a twtxt client, seems like twtxt is set to grow!

Working on a project that does Augmented Reality and computer vision object detection and QR code and image recognition inside a Web application. Pretty neat what can be done today with a few thousand lines of JavaScript.

@bender@twtxt.net https://andros.dev/texudus.txt, its url doesn’t correspond to the feed either

@lyse@lyse.isobeef.org @movq@www.uninformativ.de bbycll’s nickname regex is /^([-_\p{N}\p{L}])+$/iu because i don’t like how english-centric only allowing ascii letters/numbers is though this only applies to local users as of now, currently all nicknames are tolerated when parsing remote feeds and i just do mentions how yarn does (just the feed url)

in the wild, i’ve noticed a texedus feed with spaces in the nick (where its spec explicitly disallows whitespace in the nick) and feeds with other symbols in the nick too. honestly, i think we should just tolerate arbitrary nicknames for sake of user expression (while stripping or converting unreasonable characters) and just leave them out of mentions

is there consensus on what characters should(n’t) be allowed in nicks? i remember reading somewhere whitespace should not be allowed, but i don’t see it in the spec on twtxt.dev — in fact, are there any other resources on twtxt extensions outside of twtxt.dev?

Image

Warum ist es nur so kniffelig ein Sudoku-Rätsel zu erstellen?
Ich meine nicht, das Erstellen eines komplett ausgefüllten Sets, sondern das Leeren der Felder so, dass ein einigermaßen herausforderndes Sudoku mit nur einer Lösungsmöglichkeit entsteht. 🤔

@lyse@lyse.isobeef.org i dont mind if the hash is not backward compatible but im not sure if this is the right way to proceed because the added complexity dealing with two hash versions isnt justified

regular end users wont care to understand how twt hashes are formed, they just want to use twtxt! so i guess i could work in protecting users from themselves by disallowing post edits on old posts or posts with replies, but i’m not fond of this either really. if they want to break a thread, they can just delete the post (though i’ve noticed yarn handling post deletes dubiously…)

on activitypub i do genuinely find myself looking through several month or even year old posts sometimes and deciding to edit/reword them a little to be slightly less confusing, this should be trivial to handle on twtxt which is an infinitely simpler specification