I thought it was a general thing for browsers, but it that was actually allowed in a newer specification, yet it's still not implemented in Chrome, it does work in Firefox though.
https://movq.de/v/9df0437d27/MVI_8891.MOV.mp4
Now everything looks like it has that silly slogan as a background image:
https://movq.de/v/9df0437d27/smol.jpg
tt, I recognize umlauts in nicks, but they cannot include whitespace, @, !, #, (, ), [, ], <, >, " (but ' is okay). Whitespace also acts as a separator between nick and URL. @<Hello World http://example.com> ends up exactly like that and is not a mention.
Muy buenos The Cribs joder!
#thecribs ⌘ Read more****
https://umapenca.com/villares (BR)
#Python #CreativeCoding #Processing #py5 #TShirt #GenerativeArt #SupportArtists
white T-shirt with abstract geometric pattern made of recursively placed unfilled black stroke hexagons and lines
Buenos viernes!
Las bichos del polvo dominarán el mundo! (será una lucha encarnizada contra las ratas e Israel)
#felizViernes ⌘ Read more****
Seems that more feeds work correctly this way. 🤔
You can even "wrap" it into a packaged installation and publish it on stores, theres even projects to streamline it https://www.pwabuilder.com/.
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 ]
Currently my regex is like this:
/@<((?<nick>[^\s]+)\s)?(?<url>\w+:\/\/[^>]+)>/gIt takes everything until the space and the nick is optional.
After a long while away, I'm back on twtxt with this new feed.
Some of you might remember me as
justamoment@twtxt.net, that was a test account I made for trying things out, but I ended up keeping it more than planned.I also tried other social platforms in search of a place that felt right for me.
In the end twtxt was the one that ticked all of my boxes:
- Slow social: it act more like a feed reader and I really appreciate that there's no flood of content that I can't keep up with.
- No server needed: I absolutely love to have total control over my content, I tend to avoid having moving parts that might break, plus you can put your feed under version control and it's all backed up.
- Ownership: I can put my feed anywhere I want and nobody can decide if I can access it or not.
- For hackers: a single .txt file allows me to join a community, how cool is that!
This is why I decided to build my own twtxt client, one that allows you to decide how the feed is presented on your "instance".
It's still in the making but I'll try to share a bit of it once I defined how things should work.
Coincidentally, I discovered that @itsericwoodward and @zvava were also building a twtxt client, seems like twtxt is set to grow!
I've been working on a couple of twtxt-related projects, and one of them is a reader (tentatively called
twtstrm) written in JS. I used dummy data for the first few stages of development, but now I'm at the point where I need some _real_ data, and that meant hitting up my actual following list.Of course, it didn't help that I had a typo in my
If-Modified-Since headers, but all that has since been resolved.Anyways, if I accidentally spammed you with requests today, I am sorry, and it shouldn't happen anymore.
We thank you for your patience, and apologize for the inconvenience.
I've been working on a couple of twtxt-related projects, and one of them is a reader (tentatively called
twtstrm) written in JS. I used dummy data for the first few stages of development, but now I'm at the point where I need some _real_ data, and that meant hitting up my actual following list.Of course, it didn't help that I had a typo in my
If-Modified-Since headers, but all that has since been resolved.Anyways, if I accidentally spammed you with requests today, I am sorry, and it shouldn't happen anymore.
We thank you for your patience, and apologize for the inconvenience.
ReferenceError: account is not defined
U= (https://ciberlandia.pt/packs/direct_timeline-index-CclzgTb8.js:1:5335)
ie (https://ciberlandia.pt/packs/logo-CwPlYIww.js:15:35348)
ie (https://ciberlandia.pt/packs/logo-CwPlYIww.js:15:25299)
ie (https://ciberlandia.pt/packs/logo-CwPlYIww.js:15:35287)
U= (https://ciberlandia.pt/packs/direct_timeline-index-CclzgTb8.js:1:5304)
Ff (https://ciberlandia.pt/packs/client-DZIGVCsa.js:33:61330)
Ff (https://ciberlandia.pt/packs/client-DZIGVCsa.js:33:116588)
Ff (https://ciberlandia.pt/packs/client-DZIGVCsa.js:33:112269)
Ff (https://ciberlandia.pt/packs/client-DZIGVCsa.js:33:112197)
Ff (https://ciberlandia.pt/packs/client-DZIGVCsa.js:33:112051)
ReferenceError: account is not defined
U= (https://ciberlandia.pt/packs/direct_timeline-index-CclzgTb8.js:1:5335)
ie (https://ciberlandia.pt/packs/logo-CwPlYIww.js:15:35348)
ie (https://ciberlandia.pt/packs/logo-CwPlYIww.js:15:25299)
ie (https://ciberlandia.pt/packs/logo-CwPlYIww.js:15:35287)
U= (https://ciberlandia.pt/packs/direct_timeline-index-CclzgTb8.js:1:5304)
Ff (https://ciberlandia.pt/packs/client-DZIGVCsa.js:33:61330)
Ff (https://ciberlandia.pt/packs/client-DZIGVCsa.js:33:116588)
Ff (https://ciberlandia.pt/packs/client-DZIGVCsa.js:33:112269)
Ff (https://ciberlandia.pt/packs/client-DZIGVCsa.js:33:112197)
Ff (https://ciberlandia.pt/packs/client-DZIGVCsa.js:33:112051)
Si queréis crear controversia con vuestras opiniones, ponerlas en el estado de whatsapp, porque por aquí todos pensamos más o menos parecido.
Ya estaría.
#miOpinióndeMierda ⌘ Read more****
Não é um tema de que saiba muito para conseguir musicar apropriadamente, mas julgo que a "Fuel for Fire" dos #Metallica não fica mal:
https://youtu.be/PvF9PAxe5Ng
Não é um tema de que saiba muito para conseguir musicar apropriadamente, mas julgo que a "Fuel for Fire" dos #Metallica não fica mal:
https://youtu.be/PvF9PAxe5Ng
Não é um tema de que saiba muito para conseguir musicar apropriadamente, mas julgo que a "Fuel for Fire" dos #Metallica não fica mal:
https://youtu.be/PvF9PAxe5Ng
Dann kommt das eben in die Kiste mit den unfertigen Dingen.
https://www.youtube.com/watch?v=I-RX1GT4GT0
https://andros.dev/texudus.txt, its url doesn't correspond to the feed either
/^([-_\p{N}\p{L}])+$/iu because i don't like how english-centric only allowing ascii letters/numbers is though this only applies to local users as of now, currently all nicknames are tolerated when parsing remote feeds and i just do mentions how yarn does (just the feed url)in the wild, i've noticed a texedus feed with spaces in the nick (where its spec explicitly disallows whitespace in the nick) and feeds with other symbols in the nick too. honestly, i think we should just tolerate arbitrary nicknames for sake of user expression (while stripping or converting unreasonable characters) and just leave them out of mentions
Maybe it *does* look horribly pixelated and super ugly to other people, and that’s why everyone prefers smoothed fonts and UIs and all that … ? 😂
@<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
https://sudokupad.app/adventure/94-advvvvvvvven
I’m glad I eventually got it right. 🥴
(via https://dosgame.club/@Tijn/115221132694421937)
https://twtxt.dev/exts/metadata.html#nick
It doesn’t say much. 🤔
In the wild, I’ve only seen “traditional” nick names, i.e. ASCII 0x21 thru 0x7E.
My client removes anything but
r'[a-zA-Z0-9]' from nick names.
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?
Oxalis corniculata is growing and blossoming on my strawberries vase, giving it some unplanned color
Oxalis corniculata is growing and blossoming on my strawberries vase, giving it some unplanned color
Oxalis corniculata is growing and blossoming on my strawberries vase, giving it some unplanned color