Notes from the 2025 Git Contributor’s Summit
Taylor Blau has posted an\
extensive set of notes from the recently concluded Git Contributor’s
Summit. Covered topics include the SHA-256 transition, Rust, Change-ID
headers, Git 3.0, and many more. The note are also available on\
Google Docs for those who prefer that format. ⌘ Read more
[$] Kernel hackers at Cauldron, 2025 edition
The GNU Tools Cauldron is almost entirely focused on user-space tools, but
kernel developers need a solid toolchain too. In what appears to be a
developing tradition ( started in 2024),
some kernel developers attended the 2025 Cauldron for the
second year in a row to discuss their needs with the assembled toolchain
developers. Topics covered in this year’s gathering include Rust, better
[BPF type\
format (BTF … ⌘ Read more
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 tonick
if not defined
banner
: Using the same format asavatar
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! 🤞
(#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)
@zvava@twtxt.net the second format (the one you think should be changed to), is it backwards compatible to what’s currently in place? I believe the first one would be.
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?
@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)
@itsericwoodward@itsericwoodward.com I used the dates as is for indexing them as string, the ISO format allows for free auto sorting.
@lyse@lyse.isobeef.org Hm, I couldn’t trick yt-dlp into downloading the correct format. Works in the browser, though. 😅
@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:
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.
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.
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?
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.
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. :-)
@alexonit@twtxt.alessandrocutolo.it Personally, I find the reversed order of URL first and then timestamp more natural to reference something. Granted, URL last would be kinda consistent with the mention format. However, the timestamp doesn’t act as a link text or display text like in a mention, so, it’s some different in my opinion. But yeah.
@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 ]
nick
s? 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?
@zvava@twtxt.net @movq@www.uninformativ.de I’m not entirely sure about the spaces, but maybe they were omitted to simplify parsing of mentions in the form of @<nick url>
. If the next token after the @<nick
does not look like a URL, it’s not a mention but regular text. This is just wild guessing, though.
Looking at the regex and tests in the original twtxt reference implementation seems to confirm that theory in the sense as it relies on whitespace as the delimiter:
https://lyse.isobeef.org/tmp/screenshot-2025-09-17-21-30-25.png
Another thing about nicks is that the original twtxt reference implementation converts nicks to all lowercase:
https://lyse.isobeef.org/tmp/screenshot-2025-09-17-21-20-39.png
You probably know this already, the original twtxt file format specification can be found here: https://twtxt.readthedocs.io/en/latest/user/twtxtfile.html
As for extensions, I don’t know of anything outside of twtxt.dev that has actually been (partially) implemented. However, there is also the issue tracker of the official reference implementation. You might wanna dig through that. For example, there is an alternative suggestions of multiline messages: https://github.com/buckket/twtxt/issues/157
@kat@yarn.girlonthemoon.xyz all @prologic@twtxt.net has to do is to allow <details>
and the subset under it. Granted, it could be implemented on the formatting toolbar too…
at first i dismissed the idea of likes on twtxt as not sensible…like at all — then i considered they could just be published in a metadata field (though that field could get really unruly after a while)
retwts are plausible, as “RE: https://example.com/twtxt.txt#abcdefg
”, the hash could even be the original timestamp from the feed to make it human readable/writable, though im extremely wary of clogging up timelines
i thought quote twts could be done extremely sensibly, by interpreting a mention+hash at the end of the twt differently to when placed at the beginning — but the twt subject extension requires it be at the beginning, so the clean fallback to a normal reply i originally imagined is out of the question — it could still be possible (reusing the retwt format, just like twitter!) but i’m not convinced it’s worth it at that point
is any of this in the spirit of twtxt? no, not in the slightest, lmao
@zvava@twtxt.net may I recommend to change the mention format upon hitting reply to something similar to what it’s used in Yarn, and perhaps hiding the hash on the post too? Looking good!
Haha, fun! I browsed your gopher hole a little bit. I noticed some entries are fully justified (formatting), while others are not. I didn’t notice a pattern, though it makes sense not to use justification on entries with code. Yet, some prose entries are, and some are not. A mystery. :-)
@lyse@lyse.isobeef.org @kat@yarn.girlonthemoon.xyz I spent so much time in the past figuring out if something is a dict or a list in YAML, for example.
What are the types in this example?
items:
- part_no: A4786
descrip: Water Bucket (Filled)
price: 1.47
quantity: 4
- part_no: E1628
descrip: High Heeled "Ruby" Slippers
size: 8
price: 133.7
quantity: 1
items
is a dict containing … a list of two other dicts? Right?
It is quite hard for me to grasp the structure of YAML docs. 😢
The big advantage of YAML (and JSON and TOML) is that it’s much easier to write code for those formats, than it is with XML. json.loads()
and you’re done.
@lyse@lyse.isobeef.org yeah same YAML over XML forever bc at least one is more readable lmfao!! doesn’t forgive YAML’s crimes though… cursed formats
@movq@www.uninformativ.de @kat@yarn.girlonthemoon.xyz Any text format beats a binary configuration format. However, YAML and XML are both terrible choices in my opinion. I’d prefer YAML over XML if I had to.
Xfce does one thing very right: It stores its settings in plain-text XML files. This allows me to easily read, track, and maybe even distribute these settings to other machines.
(Unlike GNOME’s dconf, which uses some binary file format. Fun fact: The older and now deprecated gconf also used XML files.)
@prologic@twtxt.net Yeah, this really could use a proper definition or a “manifest”. 😅 Many of these ideas are not very wide spread. And I haven’t come across similar projects in all these years.
Let’s take the farbfeld image format as an example again. I think this captures the “spirit” quite well, because this isn’t even about code.
This is the entire farbfeld spec:
farbfeld is a lossless image format which is easy to parse, pipe and compress. It has the following format:
╔════════╤═════════════════════════════════════════════════════════╗
║ Bytes │ Description ║
╠════════╪═════════════════════════════════════════════════════════╣
║ 8 │ "farbfeld" magic value ║
╟────────┼─────────────────────────────────────────────────────────╢
║ 4 │ 32-Bit BE unsigned integer (width) ║
╟────────┼─────────────────────────────────────────────────────────╢
║ 4 │ 32-Bit BE unsigned integer (height) ║
╟────────┼─────────────────────────────────────────────────────────╢
║ [2222] │ 4x16-Bit BE unsigned integers [RGBA] / pixel, row-major ║
╚════════╧═════════════════════════════════════════════════════════╝
The RGB-data should be sRGB for best interoperability and not alpha-premultiplied.
(Now, I don’t know if your screen reader can work with this. Let me know if it doesn’t.)
I think these are some of the properties worth mentioning:
- The spec is extremely short. You can read this in under a minute and fully understand it. That alone is gold.
- There are no “knobs”: It’s just a single version, it’s not like there’s also an 8-bit color depth version and one for 16-bit and one for extra large images and one that supports layers and so on. This makes it much easier to implement a fully compliant program.
- Despite being so simple, it’s useful. I’ve used it in various programs, like my window manager, my status bars, some toy programs like “tuxeyes” (an Xeyes variant), or Advent of Code.
- The format does not include compression because it doesn’t need to. Just use something like bzip2 to get file sizes similar to PNG.
- It doesn’t cover every use case under the sun, but it does cover the most important ones (imho). They have discussed using something other than RGBA and decided it’s not worth the trouble.
- They refrained from adding extra baggage like metadata. It would have needlessly complicated things.
I did a “lecture”/“workshop” about this at work today. 16-bit DOS, real mode. 💾 Pretty cool and the audience (devs and sysadmins) seemed quite interested. 🥳
- People used the Intel docs to figure out the instruction encodings.
- Then they wrote a little DOS program that exits with a return code and they used uhex in DOSBox to do that. Yes, we wrote a COM file manually, no Assembler involved. (Many of them had never used DOS before.)
- DEBUG from FreeDOS was used to single-step through the program, showing what it does.
- This gets tedious rather quickly, so we switched to SVED from SvarDOS for writing the rest of the program in Assembly language. nasm worked great for us.
- At the end, we switched to BIOS calls instead of DOS syscalls to demonstrate that the same binary COM file works on another OS. Also a good opportunity to talk about bootloaders a little bit.
- (I think they even understood the basics of segmentation in the end.)
The 8086 / 16-bit real-mode DOS is a great platform to explain a lot of the fundamentals without having to deal with OS semantics or executable file formats.
Now that was a lot of fun. 🥳 It’s very rare that we do something like this, sadly. I love doing this kind of low-level stuff.
ORF-Format soll Schulklassen zu Sport motivieren ⌘ Read more
Outback community’s ethereal-looking rock formation a ‘peaceful place’
Many in the remote iron ore mining town of Pannawonica call it the Panna Hill, but Robe River Kuruma people know it as Parlapuni. ⌘ Read more
[$] The future of Flatpak
At the Linux Application\
Summit (LAS) in April, Sebastian Wick said that, by many metrics, Flatpak is doing great. The Flatpak
application-packaging format is popular with upstream developers, and
with many users. More and more applications are being published in the
Flathub application store, and the
format is even being adopted by Linux distributions like
Fedora. However, he worried that work on the Flatpak project itself
had s … ⌘ Read more
LILYGO T-Embed SI4732 Combines ESP32 S3 with All Band Radio Tuning
LILYGO has introduced a new version of its T-Embed series that incorporates the SI4732 A10 tuner module. This version supports AM, FM, shortwave, and longwave radio bands in a handheld format that visually resembles devices like the Flipper Zero. The T-Embed SI4732 uses the ESP32 S3 microcontroller with a dual-core LX7 processor clocked at 240 […] ⌘ Read more
En estos momentos, no sé si un dios le está pidiendo que libere su pueblo felino o está mirando una paloma
@sorenpeter@darch.dk No because as the spec statd originally, and we didn’t change that syntax at all:
Mentions are embedded within the text in either @ or @ format
So the lextwt parser we use will simply call this an invalid mention, which it does.
@<nick url timestamp>
) and having location based treading this way, might not break older clients, since they might just igonore the last value within the brackets.
@sorenpeter@darch.dk Unfortunately it does break all clients, because the original spec stated:
Mentions are embedded within the text in either @ or @ format
Z
for UTC +00:00
- is that allowed in your specs?
Regarding url =
I would suggest to only allow one and the maybe add url_old =
or url_alt =
!?
I'm still not a fan of a DM feature, even thou it helps that i have now been split out into a separate feed file. Instead if would suggest a contact =
field for where people can put an email or other id/link for an established chat protocol like signal or matrix.
Why are we testing, or playing with, an alternate non-fully-compatible feed format within the same feed that we use daily?
Celebrating 20 Years of the OASIS Open Document Format
The Document\
Foundation is celebrating
the 20th anniversary of the ratification of the Open Document Format
(ODF) as an OASIS
standard.
Two decades after its approval in 2005, ODF is the only open
standard for office documents, promoting digital independence,
interoperability and content … ⌘ Read more
[$] Better debugging information for inlined kernel functions
Modern compilers perform a lot of optimizations, which can complicate debugging.
Song Liu and Thierry Treyer spoke about a potential improvement to
BPF Type Format (BTF) debugging information that could partially combat that
problem at the 2025 Linux Storage, Filesystem,
Memory-Management, and BPF Summit.
They want to add information on selectively inlined functions to BTF in order to
better support tracing tools.
Trey … ⌘ Read more
What is this ‘format:’ inside of printf? ⌘ Read more
7
to 12
and use the first 12
characters of the base32 encoded blake2b hash. This will solve two problems, the fact that all hashes today either end in q
or a
(oops) 😅 And increasing the Twt Hash size will ensure that we never run into the chance of collision for ions to come. Chances of a 50% collision with 64 bits / 12 characters is roughly ~12.44B Twts. That ought to be enough! -- I also propose that we modify all our clients and make this change from the 1st July 2025, which will be Yarn.social's 5th birthday and 5 years since I started this whole project and endeavour! 😱 #Twtxt #Update
@prologic@twtxt.net I’m very sorry but my feelings are similar to @eapl.me@eapl.me . For a long time I thought that Yarn was part of the Twtxt ecosystem, and not that Twtxt is an extension of Yarn. I don’t feel comfortable with what has happened. I didn’t expect this change of direction.
The nice part of Twtxt is that it is read by humans, with a simpler format. It’s the heart of the social network.
I need to think for a little time, but I’m thinking of stopping my involvement in the community.
Nobody writes emails by hand using RFC 5322 anymore, nor do we manually send them through telnet and SMTP commands. The days of crafting emails in raw format and dialing into servers are long gone. Modern email clients and services handle it all seamlessly in the background, making email easier than ever to send and receive—without needing to understand the protocols or formats behind it! #Email #SMTP #RFC #Automation
dm-only.txt
feeds. 😂
by commenting out DMs are you giving up on simplicity? See the Metadata extension holding the data inside comments, as the client doesn’t need to show it inside the timeline.
I don’t think that commenting out DMs as we are doing for metadata is giving up on simplicity (it’s a feature already), and it helps to hide unwanted DMs to clients that will take months to add it’s support to something named… an extension.
For some other extensions in https://twtxt.dev/extensions.html (for example the reply-to hash #abcdfeg
or the mention @ < example http://example.org/twtxt.txt >
) is not a big deal. The twt is still understandable in plain text.
For DM, it’s only interesting for you if you are the recipient, otherwise you see an scrambled message like 1234567890abcdef=
. Even if you see it, you’ll need some decryption to read it. I’ve said before that DMs shouldn’t be in the same section that the timeline as it’s confusing.
So my point stands, and as I’ve said before, we are discussing it as a community, so let’s see what other maintainers add to the convo.
@andros@twtxt.andros.dev Zulu said:
what is twtxt for you?
For me Twtxt is just the underlying format that Yarn.social builds upon 😅
@bender@twtxt.net I use it. It’s not the feature I use the most in the fediverse, but I communicate this way with several friends. For example, it’s the main way I talk to the original creator of the twtxt-el repository, the way people greet me for the first time or the way they notify me of some bugs in the software I maintain. I can even tell you that it’s the main way I talk to some maintainers of the Emacs community. If there are any of you reading my words, speak up!
Why not have the same? There are things I want to say to @prologic@twtxt.net in private, why should I have to send him an email or private IRC? Or an public twt.
Of course, here’s a topic we’ve already talked about: what is twtxt for you? For me it will always be a social network, in microblogging format, but an asynchronous way of communicating. And having a tool to control visibility is basic 😄
I look forward to hearing from you @eapl.me@eapl.me !
yarnd
UI/UX experience (for those that use it) and as "client" features (not spec changes). The two ideas are quite simple:
@kate@yarn.girlonthemoon.xyz (as I was trying to say…), Glad you think so👌 My goal with Yarn.social has always been to provide the best (best that I can anyway) truly decentralised (slow) social experience that uses the Twtxt format under the hood 😅
Holy hell?! When I post this:
@<kate https://yarn.girlonthemoon.xyz/user/kat/twtxt.txt> Glad you think so! 👌 My goal with Yarn.social has always been to provide the best (_best that I can anyway!_) truly decentralised (_slow_) social experience that uses the Twtxt format under the hood 😅
Something is swallowing it.
@kate@yarn.girlonthemoon.xyz Glad you think so! 👌 My goal with Yarn.social has always been to provide the best (best that I can anyway!) truly decentralised (slow) social experience that uses the Twtxt format under the hood 😅
yarnd
UI/UX experience (for those that use it) and as "client" features (not spec changes). The two ideas are quite simple:
Glad you think so! 👌 My goal with Yarn.social has always been to provide the best (best that I can anyway!) truly decentralised (slow) social experience that uses the Twtxt format under the hood 😅
yarnd
UI/UX experience (for those that use it) and as "client" features (not spec changes). The two ideas are quite simple:
@kate@yarn.girlonthemoon.xyz Glad you think so! 👌 My goal with Yarn.social has always been to provide the best (best that I can anyway!) truly decentralised (slow) social experience that uses the Twtxt format under the hood 😅
yarnd
UI/UX experience (for those that use it) and as "client" features (not spec changes). The two ideas are quite simple:
@kate@yarn.girlonthemoon.xyz Glad you think so! 👌 My goal with Yarn.social has always been to provide the best (best that I can anyway!) truly decentralised (slow) social experience that uses the Twtxt format under the hood 😅
I asked ChatGPT what it knows about Twtxt 😂 And surprisingly it’s rather accurate:
Twtxt is a minimalist, decentralized microblogging format introduced by John Downey in 2016. It uses plain text files served over HTTP—no accounts, databases, or APIs.
In 2020, James Mills (@prologic@twtxt.net) launched Yarn.social, an extended, federated implementation with user discovery, threads, mentions, and a full web UI.
Both share the same .twtxt.txt format but differ in complexity and social features.
@prologic@twtxt.net @bmallred@staystrong.run So is restic considered stable by now? “Stable” as in “stable data format”, like a future version will still be able to retrieve my current backups. I mean, it’s at version “0.18”, but they don’t specify which versioning scheme they use.
i feel so powerful i wrote a 3 line script that takes an inputted markdown filename from the current working directory and then spits out a nicely formatted html page. pandoc does all the work i did nothing
Markdown and the Slow Fade of the Formatting Fetish - a nice article about Markdown VS proprietary formatting. With quotes like “Microsoft Office works in an office where you pretend to work until you can finally go home.” 😄
[$] Catching up with calibre
Saying that calibre is
ebook-management software undersells the application by a fair
margin. Calibre is an open-source Swiss Army knife for ebooks that can
be used for everything from creating ebooks, converting ebooks from
obscure formats to modern formats like EPUB, to serving up an ebook
library over the web. The most recent major release, calibre 8.0,
brings a better text-to-speech engine, a tool for creating audio
overlays w … ⌘ Read more
Hello, i want to present my new revolution twtxt v3 format - twjson
That’s why you should use it:
- It’s easy to to parse
- It’s easy to read (in formatted mode :D)
- It used actually \n for newlines, you don’t need unprintable symbols
- Forget about hash collisions because using full hash
Here is my twjson feed: https://doesnm.p.psf.lt/twjson.json
And twtxt2json converter: https://doesnm.p.psf.lt/twjson.js
Registry format is its own thing. It takes the regular feed and appends nick \t uri \t
to it. Its something that existed before yarn got big. There is still a bit of work but I will put together a ui for it to make it easier to view and navigate.
tt
reimplementation that I already followed with the old Python tt
. Previously, I just had a few feeds for testing purposes in my new config. While transfering, I "dropped" heaps of feeds that appeared to be inactive.
I need to import my yarn cache. It’s sitting at about 1.5G in registry format. That should make things interesting…
True. Though if the idea turns out to be better.. then community will adopt it.
if you look at the subject for that twt you will see that it uses the extended hash format to include a URL address.
** mkv no more **
My previous post included a video. I made that video with OBS which outputs .mkv
video files.
I wanted to do my best to ensure that folks with a variety of devices and browsers would be able to watch the video if they wanted to, so, I converted it into a few different formats.
Here’s the bash script I wrote to do that. It relies on ffmpeg.
”`hljs bash
#!/bin/bash
if ! command -v ffmpeg &> /dev/null; then
echo "ffmpeg ... ⌘ [Read more](https://eli.li/mkv-no-more)```
Some satisfying icicle-breaking in our backyard: photos.falsifian.org/video/sM7G3vfS6yuc/VID_20250217_203250.mp4
I couldn’t resist taking home a prize:
It’s been snowy here in #Toronto.
(I tried formatting the images in markdown for the benefit of yarn and any other clients that understand it.)
trying to keep it simple but.. perhaps it can be extended to fix timestamp formats like using " "
instead of "T"
m2049r releases Monerujo v4.1.6 with Exolix fixes
m2049r1 has released Monerujo2 patch version 4.1.63 with minor fixes - including for the Exolix 4 exchange integration - and various other changes and updates:
Minimum weblate requirements
Add Arabic Translation
Updated Swedish translation
Update Turkish and French translations
fix toolbar under notification bar
make node parsing and formatting ipv6-friendly
Update default nodes
update exolix ... ⌘ [Read more](https://monero.observer/monerujo-v4.1.6-released-exolix-fixes/)
@<url>
. Submitting this writes @<domain url>
instead of @<nick url>
in the feed.
While I now have a somewhat working fix for it in yarnd (https://git.mills.io/yarnsocial/yarn/pulls/1232), I also have the feeling that I should fix literal formatting in lextwt as well. This also uncovered more bugs I believe: https://git.mills.io/yarnsocial/go-lextwt/pulls/28
But then there is also the question why the textarea is populated with @<url>
in the first place rather than @<nick url>
or yarnd’s own @nick@domain
/@nick
syntax. It indeed has to do something with whether I follow the mentioned feed or not.
Anyway, something to investigate for future Lyse or maybe @prologic@twtxt.net and/or @xuu@txt.sour.is. G’night!
i recorded my first camcorder video!!!! it’s just me practicing guitar after sooo long of not playing it. my acoustic, to be specific (well, it’s an electric acoustic thing but i can play it without plugging it in lol, i do have a stratocaster though). it’s capped at ~30 minutes because i used one mini DVD for it and decided i wasn’t gonna use another one to extend the run time. so yeah. it was super fun! i hope i can share it soon, i’m ripping the disc with make MKV right now, then i’ll re-encode to a web friendly format, and upload to my site and hope that works well
well, the extension helps to know the file format as in .txt
and .html
, perhaps .twt
, he!
yep, my point is that the txt part is redundant for twtxt
Also a .txt file could be in any format, for example those plans from John Carmak are stored now as .txt -> https://github.com/ESWAT/john-carmack-plan-archive/blob/master/by_day/johnc_plan_19960218.txt
Although being named .plan was expected for them to work, if I recall correctly -> http://www.catb.org/jargon/html/P/plan-file.html
Great to see another user @aelaraji@aelaraji.com - And I can confirm that my #webmentions works from your server
(I know, the formatting is messed up;)@eapl.me@eapl.me here are my replies (somewhat similar to Lyse’s and James’)
Metadata in twts: Key=value is too complicated for non-hackers and hard to write by hand. So if there is a need then we should just use #NSFS or the alt-text file in markdown image syntax

if something is NSFWIDs besides datetime. When you edit a twt then you should preserve the datetime if location-based addressing should have any advantages over content-based addressing. If you change the timestamp the its a new post. Just like any other blog cms.
Caching, Yes all good ideas, but that is more a task for the clients not the serving of the twtxt.txt files.
Discovery: User-agent for discovery can become better. I’m working on a wrapper script in PHP, so you don’t need to go to Apaches log-files to see who fetches your feed. But for other Gemini and gopher you need to relay on something else. That could be using my webmentions for twtxt suggestion, or simply defining an email metadata field for letting a person know you follow their feed. Interesting read about why WebMetions might be a bad idea. Twtxt being much simple that a full featured IndieWeb sites, then a lot of the concerns does not apply here. But that’s the issue with any open inbox. This is hard to solve without some form of (centralized or community) spam moderation.
Support more protocols besides http/s. Yes why not, if we can make clients that merge or diffident between the same feed server by multiples URLs
Languages: If the need is big then make a separate feed. I don’t mind seeing stuff in other langues as it is low. You got translating tool if you need to know whats going on. And again when there is a need for easier switching between posting to several feeds, then it’s about building clients with a UI that makes it easy. No something that should takes up space in the format/protocol.
Emojis: I’m not sure what this is about. Do you want to use emojis as avatar in CLI clients or it just about rendering emojis?
description
header. Or rather, how often it re-fetches it.
So, @prologic@twtxt.net, Yarn isn’t rendering the metadata
as described on the format documentation. That is, ux2028
is ignored when Yarn renders the description
metadata.
@Codebuzz@www.codebuzz.nl I use Jenny to add to a local copy of my twtxt.txt file, and then manually push it to my web servers. I prefer timestamps to end with “Z” rather than “+00:00” so I modified Jenny to use that format. I mostly follow conversations using Jenny, but sometimes I check twtxt.net, which could catch twts I missed.
@codebuzz@www.codebuzz.nl I have some shell scripts that handle some of the log formatting details, but I mostly write my mesages by hand. Lately I’ve been browsing twtxt.net since they aggregate most of the known network. I have a couple of demo aggregators sitting around, but I’m in the middle of some infra rebuilds so a lot of my services are offline rn. They’re both built on a simple social graph analysis that extracts urls for your direct follows the follows listed on each of those feeds (friend-of-a-friend replication). certain formatting operations are awkward with my setup, so I may write an app of some kind in the future. likely gemini-based, but I have a number of projects ahead of that one in the queue.
👋 PR to propose Feed Format Extension – Request for comment 🙏
@prologic@twtxt.net I’m not a yarnd user, so it doesn’t matter a whole lot to me, but FWIW I’m not especially keen on changing how I format my twts to work around yarnd’s quirks.
I wonder if this kind of postprocessing would fit better between composing (via yarnd’s UI) and publishing. So, if a yarnd user types ¼, it could get changed to ¼ in the twtxt.txt file for everyone to see, not just people reading through yarnd. But when I type ¼, meaning first out of four, as a non-yarnd user, the meaning wouldn’t get corrupted. I can always type ¼ directly if that’s what I really intend.
(This twt might be easier to understand if you read it without any transformations :-P)
Anyway, again, I’m not a yarnd user, so do what you will, just know you might not be seeing exactly what I meant.
@prologic@twtxt.net One could argue twtxt.net’s display formatting is a little over-eager here.
@Codebuzz@www.codebuzz.nl Speed is an issue for the client software, not the format itself, but yes I agree that it makes the most sense to append post to the end of the file. I’m referring to the definition that it’s the first url =
in the file that is the one that has to be used for the twthash computation, which is a too arbitrary way of defining something that breaks treading time and time again. And this is the case for not using url+date+message = twthash.
[ANN] Understanding Jamtis: A New Addressing Scheme for Monero
By simplifying how addresses are shared, speeding up wallet synchronization, and ensuring more reliable output detection, Jamtis represents a big leap forward in usability—without sacrificing Monero’s commitment to privacy and security.
Link: https://kewbit.org/understanding-jamtis-a-new-address-format-for-monero/
KewbitXMR (Github) ⌘ Read more
Idk about other pubnixes but i can freely edit caddy config (or change webserver and use other config format)
twet display twts in raw format with some formatting (sadly no newlines). And for reply messages i just seen (#hash). But which text hidden on hash? currenly im open twtxt.net/twt/hash to see this
@lyse@lyse.isobeef.org on this:
3.2 Timestamps: I feel no need to mandate UTC. Timezones are fine with me. But I could also live with this new restriction. I fail to see, though, how this change would make things any easier compared to the original format.
Exactly! If anything it will make things more complicated, no?
Good writeup, @anth@a.9srv.net! I agree to most of your points.
3.2 Timestamps: I feel no need to mandate UTC. Timezones are fine with me. But I could also live with this new restriction. I fail to see, though, how this change would make things any easier compared to the original format.
3.4 Multi-Line Twts: What exactly do you think are bad things with multi-lines?
4.1 Hash Generation: I do like the idea with with a new uuid
metadata field! Any thoughts on two feeds selecting the same UUID for whatever reason? Well, the same could happen today with url
.
5.1 Reply to last & 5.2 More work to backtrack: I do not understand anything you’re saying. Can you rephrase that?
8.1 Metadata should be collected up front: I generally agree, but if the uuid
metadata field were a feed URL and no real UUID, there should be probably an exception to change the feed URL mid-file after relocation.
why can we both have a format that you can write by hand and better clients?
Some more arguments for a local-based treading model over a content-based one:
The format:
(#<DATE URL>)
or(@<DATE URL>)
both makes sense: # as prefix is for a hashtag like we allredy got with the(#twthash)
and @ as prefix denotes that this is mention of a specific post in a feed, and not just the feed in general. Using either can make implementation easier, since most clients already got this kind of filtering.Having something like
(#<DATE URL>)
will also make mentions via webmetions for twtxt easier to implement, since there is no need for looking up the#twthash
. This will also make it possible to make 3th part twt-mentions services.Supporting twt/webmentions will also increase discoverability as a way to know about both replies and feed mentions from feeds that you don’t follow.
I wrote some code to try out non-hash reply subjects formatted as (replyto ), while keeping the ability to use the existing hash style.
I don’t think we need to decide all at once. If clients add support for a new method then people can use it if they like. The downside of course is that this costs developer time, so I decided to invest a few hours of my own time into a proof of concept.
With apologies to @movq@www.uninformativ.de for corrupting jenny’s beautiful code. I don’t write this expecting you to incorporate the patch, because it does complicate things and might not be a direction you want to go in. But if you like any part of this approach feel free to use bits of it; I release the patch under jenny’s current LICENCE.
Supporting both kinds of reply in jenny was complicated because each email can only have one Message-Id, and because it’s possible the target twt will not be seen until after the twt referencing it. The following patch uses an sqlite database to keep track of known (url, timestamp) pairs, as well as a separate table of (url, timestamp) pairs that haven’t been seen yet but are wanted. When one of those “wanted” twts is finally seen, the mail file gets rewritten to include the appropriate In-Reply-To header.
Patch based on jenny commit 73a5ea81.
https://www.falsifian.org/a/oDtr/patch0.txt
Not implemented:
- Composing twts using the (replyto …) format.
- Probably other important things I’m forgetting.
i feel like we should isolate a subset of markdown that makes sense and built it into lextwt. it already has support for links and images. maybe basic formatting bold, italic. possibly block quote and bullet lists. no tables or footnotes
@prologic@twtxt.net Wikipedia claims sha1 is vulnerable to a “chosen-prefix attack”, which I gather means I can write any two twts I like, and then cause them to have the exact same sha1 hash by appending something. I guess a twt ending in random junk might look suspcious, but perhaps the junk could be worked into an image URL like
. If that’s not possible now maybe it will be later.git only uses sha1 because they’re stuck with it: migrating is very hard. There was an effort to move git to sha256 but I don’t know its status. I think there is progress being made with Game Of Trees, a git clone that uses the same on-disk format.
I can’t imagine any benefit to using sha1, except that maybe some very old software might support sha1 but not sha256.
Hey, @movq@www.uninformativ.de, a tiny thing to add to jenny
, a -v
switch. That way when you twtxt “That’s an older format that was used before jenny version v23.04”, I can go and run jenny -v
, and “duh!” myself on the way to a git pull
. :-D
@movq@www.uninformativ.de alright, fair, and interesting. I was expecting them to be all the same (format wise), but it doesn’t matter, for sure, as it works just fine. Thanks!
@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
@movq@www.uninformativ.de Non-ASCII characters were broken. Like U+2028, degrees (°), etc.
Turns out I used a silly library to detect the encoding and transform to UTF-8 if needed. When there is no Content-Type header, like for local files, it looks at the first 1024 bytes. Since it only saw ASCII in that region, the damn thing assumed the data to be in Windows-1252 (which for web pages kinda makes sense):
// TODO: change default depending on user's locale?
return charmap.Windows1252, "windows-1252", false
https://cs.opensource.google/go/x/net/+/master:html/charset/charset.go;l=102
This default is hardcoded and cannot be changed.
Trying to be smart and adding automatic support for other encodings turned out to be a bad move on my end. At least I can reduce my dependency list again. :-)
I now just reject everything that explicitly specifies something different than text/plain
and an optional charset other than utf-8
(ignoring casing). Otherwise I assume it’s in UTF-8 (just like the twtxt file format specification mandates) and hope for the best.
url
field in the feed to define the URL for hashing. It should have been the last encountered one. Then, assuming append-style feeds, you could override the old URL with a new one from a certain point on:
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 ?
A Simple Archive Format for Self-Contained Executables
The build/run instructions for the example games for
high_impact were subtly wrong:
make sokol
./build/game_sokol
make sokol
compiles the Sokol version, converts all assets and puts the results
(executable and converted assets) into the build/
directory. So far so good.
Where it falls apart is in the next line: ./build/game_sokol
. The executable
starts just fine, but it’s looking in the current directory ( ./
) for all the
assets, … ⌘ Read more
@bender@twtxt.net it sure breaks the index formatting.
Here’s Everything New in the Messages App on iOS 18
iOS 18 adds many new features to the Messages app, including the ability to schedule messages to be sent later, the ability to use any emoji or sticker as a Tapback, text formatting options like bold and italics, and much more.
iOS 18 is currently available in beta for members of the Apple Developer Program, with … ⌘ Read more
What’s a PXM File & How Do You Open It?
File types and file formats can be a bit of a mystery, especially when you stumble into a file that you don’t necessarily recognize. One such case that you may come across is a file that has a .pxm file extension, and if you haven’t heard of a PXM file before you understandably might be … Read More ⌘ Read more
How to Convert MOV to MP4 on Mac Free with ffmpeg
If you have a video file in MOV format, you may wish to convert the MOV video to MP4 format instead. While there are a variety of methods for converting MOV to MP4, the approach we’re going to address here is by using the command line, with a super easy to use and free tool … Read More ⌘ Read more
Create a Resume with Pages on Mac, iPhone, iPad
Creating a resume is one of those tasks that can be stressful, but it does not need to be if you’re in the Apple ecosystem. That’s because your iPhone, iPad, and Mac, all have a readily accessible series of resume templates that you can access. Whether it’s updating a resume into a new format, or … Read More ⌘ Read more
Create a Resume with Pages on Mac, iPhone, iPad
Creating a resume is one of those tasks that can be stressful, but it does not need to be if you’re in the Apple ecosystem. That’s because your iPhone, iPad, and Mac, all have a readily accessible series of resume templates that you can access. Whether it’s updating a resume into a new format, or … Read More ⌘ Read more
@lyse@lyse.isobeef.org its a hierarchy key value format. I designed it for the network peering tools i use.. I can grant access to different parts of the tree to other users.. kinda like directory permissions. a basic example of the format is:
@namespace
# multi
# line
# comment
root :value
# example space comment
@namespace.name space-tag
# attribute comments
attribute attr-tag :value for attribute
# attribute with multiple
# lines of values
foo :bar
:bin
:baz
repeated :value1
repeated :value2
each @
starts the definition of a namespace kinda like [name]
in ini format. It can have comments that show up before. then each attribute is key :value
and can have their own #
comment lines.
Values can be multi line.. and also repeated..
the namespaces and values can also have little meta data tags added to them.
the service can define webhooks/mqtt topics to be notified when the configs are updated. That way it can deploy the changes out when they are updated.
Yeah, the lack of comments makes regular JSON not a good configuration format in my view. Also, putting all keys in quotes and the use of commas is annoying. The big upside is that’s in lots of standard libraries.
I think the appeal with YAML is that is has comments, is kind of easy to write and read and also provides unlimited nesting levels. But it has all its drawbacks, no question. Forbidding tabs, thousands of different string flavors, having so many boolean options (poor Norwegians) etc. I use it, but I don’t particularly enjoy it.
Among simple key value pairs, I like INI files, but with #
for comments, not ;
. I never used TOML, read up on it yesteray before writing this question, but it looks a bit weird and has some strange rules. I guess I have to give it a try one day.
And yes, as mentioned by several of you, it always depends on the complexity of the configuration at hand.
I’m developing something for the scouts at the moment with rather simple requirements on the config. Currently, there are just four settings. Even INI would be overkill with its section. I selected JSON for now, because that’s readily available with Go’s std lib. But I do not like it.
Btw. what’s your own config format, @xuu@txt.sour.is?
Question of the day: What configuration file formats do you all like and use?
How to Mount & Copy HFS Classic Mac Drives on MacOS
Modern versions of MacOS no longer support HFS, meaning that new Macs can no longer read, mount, or write to classic HFS drives. But a fair amount of longtime Mac users continue to have older Macs and old Mac hard drives that are in HFS format, way back from the days of Mac OS 8, … Read More ⌘ Read more
Palestinian Prime Minister Shtayyeh submits resignation
Palestinian Prime Minister Mohammad Shtayyeh said on Monday he was resigning to allow for the formation of a broad consensus among Palestinians about political arrangements following Israel’s war against the Islamist group Hamas in Gaza. ⌘ Read more
Status 2024-02-25
Status report again!
Sitting in front of the wood stove in my country cottage. It’s nice
and quiet. Meanwhile it seems NordicFuzzCon is going on in Malmö.
4,000 furries. I had no idea! That seems fun!
On the other hand I just read that at least 10,000 were protesting in
Malmö today against the Israel-Palestine conflict. I’ve seen the much
smaller protest … ⌘ Read more
The country music vamp n’ talk is a nice format. A stolen-from-the-blues-thing? I like the vibe of someone pouring out their heart into the mic in plain speech while their friends pour their hearts into their instruments gently in the background.
How to Batch Convert Images to WebP on Mac
As WebP grows in popularity as a compressed image format for the web, many web workers need to convert batches of images to WebP format from their Mac. Bulk converting images like JPG and PNG to WebP is not currently a native feature, but with a little tinkering on the Mac, you can gain functionality … Read More ⌘ Read more
After getting used to it, I’m loving this date format:
2024-02-06
I liked ‘6feb2024’, although isn’t as international as the former.
And… ‘06/02/24’ is awful, don’t use it!