access.log files. Hence theyâll never see followers, unless we notify them out of band. đ«€
@movq@www.uninformativ.de Actually, @threatcat@tilde.club popped up in my own access log first. Thatâs how I discovered the feed. :-) So I figured that this feed author actually sees my reply. The hope is that with the next mention of my feed in threatcatâs feed, the other tilde users, who are following threatcat, are then also informed of my existence. :-)
I donât know how tilde.club is set up. But it should be relatively easy to give all users access to their nginx access logs. Not sure if somebody already requested that or not. But Iâd encourage tilde users to ask for that. Maybe also just for twtxt.txt and/or in a custom, reduced log format.
@movq@www.uninformativ.de Itâs formatted just fine đ€
This is formatted poorly on twtxt.net, so hereâs a plain text file: https://movq.de/v/971c5a125d/wall-of-text.txt
Linus Says Rust Formatting is âBass-Ackwards Garbageâ
â[Rustfmtcheck] is just ANNOYING. â Read more
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 tonickif not defined
banner: Using the same format asavatarbut 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 ]
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?
@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. :-)
Prosodical Thoughts: Debian repository key change
We have been working on some changes to our Debian/Ubuntu package repository.
If you use our repository to keep up to date with new Prosody packages, you
need to take action before 4th August 2025 to continue receiving updates
smoothly.
The âaptâ utility has been moving towards a new format for specifying package
repositories. If you are familiar with putting deb lines in a sources.list
file, [that method is changing](ht ⊠â Read more
@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
Paste Without Formatting Should be the Default
Software needs to stop trying to be so dang fancy. â Read more
NATO announces new Ramstein format meeting next week â Read more
One of the Last Linux Magazines Ends Print Publication
Linux Format Magazine ends publication after 25 years - joining Linux Journal, Ubuntu User, Maximum Linux and many other now-dead Linux publications. â 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
10 Invisible Standards That Make the Modern World Work
Modern life feels seamless. You buy a phone charger, and it fits. You send a letter, and it gets delivered. But behind that convenience is a complex web of invisible global standardsâquiet, often century-old decisions that the entire planet just agreed to follow. Without them, your printer wouldnât know how to format a page, your [âŠ]
The post [10 Invisible Standards That Make the Modern World Work](https://listverse.com/20 ⊠â 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
OSTIF Announces NATS Security Audit Results
OSTIF is proud to share the results of our security audit of NATS. NATS is an open source project made by Synadia Communications for secure always-on messaging for a variety of digital formats and clients. With⊠â Read more
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
Managing multi-line logs with Fluent Bit and Python
In this blog you will learn about: Introduction Logs are essential for monitoring and debugging applications, but not all logs are created equal. While most logs follow a simple line-by-line format, others span multiple lines to⊠â Read more
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
New format for chunin exam â 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.
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âŠ
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.
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"
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
Todayâs date, 24.12.24 (using the German date format, DD.MM.YY), is special in a quirky mathematical way! Notice how 12 (the month) is exactly half of 24 (the day and the year). This symmetry adds an extra layer of charm to an already magical time of the year. Itâs a rare alignment that makes this Christmas Eve uniquely memorable. â Read more
Appleâs 3D video is uncomfortable viewing â and thatâs a good thing
Wearing special glasses to see depth in your movies did not take off. Apple hopes its ecosystem of creatives and developers will help its own 3D format fare better. â Read more
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.
Ce que rĂ©vĂšle lâouragan Helene de lâadministration Biden-Harris
Le 27 septembre dernier, un vĂ©ritable dĂ©luge sâabattait sur plusieurs comtĂ©s de Caroline du Nord et du Tennessee aux Ătats-Unis : HĂ©lĂšne, ouragan alors passĂ© en tempĂȘte tropicale, dĂ©versait des trombes dâeau sur les Appalaches entraĂźnant la formation de fleuves de boue massifs qui ont tout emportĂ©. Et comme nous sommes aux Ătats-Unis, le chaos se [âŠ] â Read more
[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