Emperor Palpatine
⌘ Read more

Planetary Rings
⌘ Read more

Physics Paths
⌘ Read more

Physics Insight
⌘ Read more

Hot Water Balloon
⌘ Read more

Skateboard
⌘ Read more

Ping
⌘ Read more

Measure Twice, Cut Once
⌘ Read more

Hopefully I can muster up the energy to start this new project:

Put up lots of thermometers and hygrometers in the apartment, have them report their readings wireless to a database.

I suspect that I’ll have to “build” these myself, because ready-to-use kits most like require some sort of cloud service. Dunno, haven’t checked yet.

100% All Achievements
⌘ Read more

@prologic@twtxt.net this is 90 degrees fork. Now that you mention being conservative socialist (first I heard of the term, had to read some to grasp what’s all about), what do think about immigration and multiculturalism?

@prologic@twtxt.net how dare you! (read it with Greta emphasis, and accent)

@zvava@twtxt.net Going to have to hard disagree here I’m sorry. a) no-one reads the raw/plain twtxt.txt files, the only time you do is to debug something, or have a stick beak at the comments which most clients will strip out and ignore and b) I’m sorry you’ve completely lost me! I’m old enough to pre-date before Linux became popular, so I’m not sure what UNIX principles you think are being broken or violated by having a Twt Subject (Subject) whose contents is a cryptographic content-addressable hash of the “thing”™ you’re replying to and forming a chain of other replies (a thread).

I’m sorry, but the simplest thing to do is to make the smallest number of changes to the Spec as possible and all agree on a “Magic Date” for which our clients use the modified function(s).

Hiking
⌘ Read more

@bender@twtxt.net Thanks for asking!

So, I’ve been working on 2 main twtxt-related projects.

The first is small Node / express application that serves up a twtxt file while allowing its owner to add twts to it (or edit it outright), and I’ve been testing it on my site since the night I made that post. It’s still very much an MVP, and I’ve been intermittently adding features, improving security, and streamlining the code, with an eye to release it after I get an MVP done of project #2 (the reader).

But that’s where I’ve been struggling. The idea seems simple enough - another Node / express app (this one with a Vite-powered front-end) that reads a public twtxt file, parses the “follow” list, grabs (and parses) those twtxt files, and then creates a river of twts out of the result. The pieces work fine in seclusion (and with dummy data), but I keep running into weird issues when reading real-live twtxt files, so some twts come through, while others get lost in the ether. I’ll figure it out eventually, but for now, I’ve been spending far more time than I anticipated just trying to get it to work end-to-end.

On top of it, the 2 projects wound up turning into 4 (so far), as I’ve been spinning out little libraries to use across both apps (like https://jsr.io/@itsericwoodward/fluent-dom-esm, and a forthcoming twtxt helper library).

In the end, I’m hoping to have project 1 (the editor) into beta by the end of October, and project 2 (the reader) into beta sometime after that, but we’ll see.

I hope this has satisfied your curiosity, but if you’d like to know more, please reach out!

@bender@twtxt.net Thanks for asking!

So, I’ve been working on 2 main twtxt-related projects.

The first is small Node / express application that serves up a twtxt file while allowing its owner to add twts to it (or edit it outright), and I’ve been testing it on my site since the night I made that post. It’s still very much an MVP, and I’ve been intermittently adding features, improving security, and streamlining the code, with an eye to release it after I get an MVP done of project #2 (the reader).

But that’s where I’ve been struggling. The idea seems simple enough - another Node / express app (this one with a Vite-powered front-end) that reads a public twtxt file, parses the “follow” list, grabs (and parses) those twtxt files, and then creates a river of twts out of the result. The pieces work fine in seclusion (and with dummy data), but I keep running into weird issues when reading real-live twtxt files, so some twts come through, while others get lost in the ether. I’ll figure it out eventually, but for now, I’ve been spending far more time than I anticipated just trying to get it to work end-to-end.

On top of it, the 2 projects wound up turning into 4 (so far), as I’ve been spinning out little libraries to use across both apps (like https://jsr.io/@itsericwoodward/fluent-dom-esm, and a forthcoming twtxt helper library).

In the end, I’m hoping to have project 1 (the editor) into beta by the end of October, and project 2 (the reader) into beta sometime after that, but we’ll see.

I hope this has satisfied your curiosity, but if you’d like to know more, please reach out!

@prologic@twtxt.net I know we won’t ever convince each other of the other’s favorite addressing scheme. :-D But I wanna address (haha) your concerns:

1. I don’t see any difference between the two schemes regarding link rot and migration. If the URL changes, both approaches are equally terrible as the feed URL is part of the hashed value and reference of some sort in the location-based scheme. It doesn’t matter.

2. The same is true for duplication and forks. Even today, the “cannonical URL” has to be chosen to build the hash. That’s exactly the same with location-based addressing. Why would a mirror only duplicate stuff with location- but not content-based addressing? I really fail to see that. Also, who is using mirrors or relays anyway? I don’t know of any such software to be honest.

3. If there is a spam feed, I just unfollow it. Done. Not a concern for me at all. Not the slightest bit. And the byte verification is THE source of all broken threads when the conversation start is edited. Yes, this can be viewed as a feature, but how many times was it actually a feature and not more behaving as an anti-feature in terms of user experience?

4. I don’t get your argument. If the feed in question is offline, one can simply look in local caches and see if there is a message at that particular time, just like looking up a hash. Where’s the difference? Except that the lookup key is longer or compound or whatever depending on the cache format.

5. Even a new hashing algorithm requires work on clients etc. It’s not that you get some backwards-compatibility for free. It just cannot be backwards-compatible in my opinion, no matter which approach we take. That’s why I believe some magic time for the switch causes the least amount of trouble. You leave the old world untouched and working.

If these are general concerns, I’m completely with you. But I don’t think that they only apply to location-based addressing. That’s how I interpreted your message. I could be wrong. Happy to read your explanations. :-)

@prologic@twtxt.net I can see the issues mentioned, but I think some can be fixed.

1. The current hash relies on a url field too, by specification, it will use the first # url = <URL> in the feed’s metadata if present, that too can be different from the fetching source, if that field changes it would break the existing hashes too, a better solution would be to use a non-URL key like # feed_id = <UNIQUE_RANDOM_STRING> with the url as fallback.

2. We can prevent duplications if the reference uses that same url field too or the client “collapse” any reference of all the urls defined in the metadata.

3. I agree that hashing based on content is good, but we still use the URL as part of the hashing, which is just a field in the feed, easily replicable by a bot, also noting that edits can also break the hash, for this issue an alternative solution (E.g. a private key not included in the feed) should be considered.

4. For offline reading the source would be downloaded already, the fetching of non followed feeds would fill the gap in the same way mentions does, maybe I’m missing some context on this one.

5. To prevent collisions there was a discussion on extending the hash (forgot if that was already fixed or not), but without a fallback that would break existing clients too, we should think of a parallel format that maintains current implementations unchanged, we are already backward compatible with the original that don’t use threads at all, a mention style format for that could be even more user-friendly for those clients.

We should also keep in mind that the current mention format is already location based (@<example https://example.com/twtxt.txt>) so I’m not that worried about threads working the same way.

Hope to see some other thought about this matter. 🤓

Here is just a small list of things™ that I’m aware will break, some quite badly, others in minor ways:

1. Link rot & migrations: domain changes, path reshuffles, CDN/mirror use, or moving from txt → jsonfeed will orphan replies unless every reader implements perfect 301/410 history, which they won’t.
   
2. Duplication & forks: mirrors/relays produce multiple valid locations for the same post; readers see several “parents” and split the thread.
   
3. Verification & spam-resistance: content addressing lets you dedupe and verify you’re pointing at exactly the post you meant (hash matches bytes). Location anchors can be replayed or spoofed more easily unless you add signing and canonicalization.
   
4. Offline/cached reading: without the original URL being reachable, readers can’t resolve anchors; with hashes they can match against local caches/archives.
   
5. Ecosystem churn: all existing clients, archives, and tools that assume content-derived IDs need migrations, mapping layers, and fallback logic. Expect long-lived threads to fracture across implementations.

@bender@twtxt.net Seriously I have zero clue 🤣 I don’t read or watch any news so I have no idea 🤦‍♂️

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?

Adding too this. The configuration example at the repository reads:

{
	"nick": "Example",
	"description": "alice's twtxt instance!",
	"host": "twtxt.example.com",
	"admin": "alice"
}

Would it make more sense changing nick to instance_name or similar? Usually nick is reserved for users, like here, quark. Right? Also, is host the same FQDN to be used while proxying traffic to the application? That is, using the above configuration, it’s Caddy configuration would be:

twtxt.example.com {
	encode
	reverse_proxy :31212
}

Is that correct?

On the configuration topic, the example at the repo reads like this:

“

wait why are so many of my post hashes not generating correctly ;w;

edit: i read the spec wrong :3 only +/-00:00 is stripped, not the entire timezone offset >.<

@prologic@twtxt.net excellent, mate, that’s what we like to read! Enjoy the weekend!

@kat@yarn.girlonthemoon.xyz Ta. The only good use for <details> is to collapse long logs in bug analysis reports. Other than that, I find it rather annoying to expand sections manually.

As for spoilers, personally, I don’t care at all. Not the slightest bit. If there is something that I don’t wanna read, I just stop reading. ¯_(ツ)_/¯

But I’ve got the feeling that I’ve got an unpopular opinion on that matter. ;-)

@movq@www.uninformativ.de @kat@yarn.girlonthemoon.xyz Thanks! :-) I was reading the gakw manual when it started and caught up on the eels later. :-)

@movq@www.uninformativ.de Holy shit, that’s insane! :-D I tried it, but i’m absolutely terrible at these type of games. I’m having trouble with the keys to move around. Maybe after ages I would pick it up and it becomes natural. I just was never a real gamer.

I will definitely try to read through the code, though! This looks sick. 8-)

@movq@www.uninformativ.de Interesting, yes. I didn’t know that.

No AI being used is really great. However, the same clips shown over and over again and some images being mirrored was quite annoying to me. Also, there were some quite terrible computer animations and sometimes the narration and picture didn’t match at all. Talking about the medieval period and then showing an image from the 18th hundred or so. What the heck?

These production issues made me sceptical pretty much early on. So I quickly crosschecked Wikipedia. But it seems spot on from what I’ve read. Very good. Also, the narrator’s voice was really nice to listen to.

Eels are fascinating creatures. :-)

@lyse@lyse.isobeef.org @dce@hashnix.club It’s pretty cool, I won’t argue that, but also really simple, to be completely honest. 😅 The BIOS already provides all you need to send data to the printer:

https://helppc.netcore2k.net/interrupt/bios-printer-services

The BIOS actually does provide a great deal of things, which, to me, was one of the most surprising learnings of this project (the project of writing a little 16-bit real-mode OS, that is). It often doesn’t feel like I was writing an operating system – it felt more like writing a normal program that just uses BIOS calls like we would use syscalls these days.

(I’ve also read a lot of warnings, like “don’t use the BIOS for this or that”. Mostly because it tends to be very slow.)

Right, now that I’m reading some comments: I was initially assuming that they would actually make it impossible for distros to provide a 32-bit build (intentionally or unintentionally). But maybe that’s not the case and distros can just continue to ship a 32-bit Firefox …

@lyse@lyse.isobeef.org I’m looking for an OS that runs better than Windows (🤮) and through which I can do basic stuff like read RSS feeds and browse geminispace; but which I can also learn from.

@dce@hashnix.club You should try los86! 8-)

Well, what are you trying to do on this ThinkPad? That might affect the OS choices.

I really had to laugh when I read your initial comparison. I love it! :-D

Hmm, gnu.org is slow as heck. Shorter HTML pages load in about ten seconds. This complete AWK manual all in one large HTML page took a full minute: https://www.gnu.org/software/gawk/manual/gawk.html Is there maybe some anti AI shenanigans going on?

In any case, I find the user guide super interesting. My AWK skills are basically non-existent, so I finally decided to change that. This document is incredibly well written and makes it really fun to keep reading and learning. I’m very impressed. So far, I made it to section 1.6, happy to continue.

@zvava@twtxt.net oh duh! Sorry, I promised I read, my brain just didn’t process it right. I shall follow your progress, and offer bits and pieces of unrequested trivialities. :-)

@bender@twtxt.net ..if you read the post you would see those are the next planned steps, yes

@lyse@lyse.isobeef.org (Haha, every time I read the word “Gophers”, I have to stop and remind myself that this is about Golang. 🤪)

@movq@www.uninformativ.de That’s rather a nice phlog right there. Really enjoyed reading it.

@movq@www.uninformativ.de Oh, nice read!

If I’m in the woods, I’d like to not waste my time with computers and focus on the beauty of nature. ;-) So, I’m not gonna participate in that event. But I’d read your articles on that subject anytime. :-)

@movq@www.uninformativ.de that works! Reading! :-)

@klaxzy@klaxzy.net I’ve had many SD cards die in Raspberry Pis. Really annoying. I’ve eventually switched to using a read-only rootfs. 🫤

@dce@hashnix.club Yeah, I’ve read about that approach. Sounds clever. Truth is, I’m too tired. 😢 I don’t want to spend too much of my time fighting assholes.

I’ve now started blocking entire cloud hosters. Sorry, not sorry.

As expected: Didn’t last long. They’re coming from different IPs now.

I’ve read enough blog posts by other people to know that this is probably pointless. The bots have so many IPs/networks at their disposal …

I’ve got a prototype of my hardcopy simulator going. I’m typing on the keyboard and the “display” goes to the printer:

https://movq.de/v/56feb53912/s.png

https://movq.de/v/235c1eabac/MVI_8810.MOV.mp4

The biiiiiiiiiig problem is that the print head and plastic cover make it impossible to see what’s currently being printed, because this is not a typewriter. This means: In order to see what I just entered, I have to feed the paper back and forth and back and forth … it’s not ideal.

I got that idea of moving back/forth from Drew DeVault, who – as it turned out – did something similar a few years back. (I tried hard to read as little as possible of his blog post, because figuring things out myself is more fun. But that could mean I missed a great idea here or there.)

But hey, at least this is running on my Pentium 133 on SuSE Linux 6.4, printer connected with a parallel cable. 😍

(Also, yes, you can see the printouts of earlier tests and, yes, I used ed(1) wrong at one point. 🤪 And ls insisted on using colors …)

@prologic@twtxt.net Yes, this is another instance of restricting “personal” computing. You won’t be able to install arbitrary software anymore (“sideloading”, as they call it).

It’s not unique, it’s not new. Boiling the frog alive.

We’re heading towards this: https://www.gnu.org/philosophy/right-to-read.html

@movq@www.uninformativ.de Yeah I just got a bit curious after watching your video and reading your OP 😅

Hahaha, I first thought of https://www.youtube.com/watch?v=zA52uNzx7Y4

when I read @kat@yarn.girlonthemoon.xyz’s “lyrics”. ;-)

Doesn’t sound bad, I like it. The synth reminded me of some song by Beast in Black.

mandoc is nicer to read/write than the man macro package and, most importantly, it’s semantic markup.

HTML output is a bit broken in GNU groff, though (OpenBSD on the left, GNU on the right):

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

🤔

Still, I’m inclined to convert my manpages to mandoc.

@kingdomcome@yarn.girlonthemoon.xyz Yeah, it’s all about simplicity. That’s what got me hooked. In its original form without the extensions, you can even read the raw feed and it doesn’t feel all that bad.

Heck yeah, that’s damn cool: Reading QR codes without a computer! https://qr.blinry.org/