I have applied your comments, and I tried to add you as an editor but couldnât find your email address. Please request editing access if you wish.
Also, could you elaborate on how you envision migrating with a script? You mean that the client of the file owner could massively update URLs in old twts ?
@andros@twtxt.andros.dev Can you reproduce any of this outside of your client? I canât spot a mistake here:
$ curl -sI 'http://movq.de/v/8684c7d264/.html%2Dindex%2Dthumb%2Dgimp11%2D1.png.jpg'
HTTP/1.1 200 OK
Connection: keep-alive
Content-Length: 2615
Content-Type: image/jpeg
Date: Wed, 19 Mar 2025 19:53:17 GMT
Last-Modified: Wed, 19 Mar 2025 17:34:08 GMT
Server: OpenBSD httpd
$ curl -sI 'https://movq.de/v/8684c7d264/gimp11%2D1.png'
HTTP/1.1 200 OK
Connection: keep-alive
Content-Length: 131798
Content-Type: image/png
Date: Wed, 19 Mar 2025 19:53:19 GMT
Last-Modified: Wed, 19 Mar 2025 17:18:07 GMT
Server: OpenBSD httpd
$ telnet movq.de 80
Trying 185.162.249.140...
Connected to movq.de.
Escape character is '^]'.
HEAD /v/8684c7d264/.html%2Dindex%2Dthumb%2Dgimp11%2D1.png.jpg HTTP/1.1
Host: movq.de
Connection: close
HTTP/1.1 200 OK
Connection: close
Content-Length: 2615
Content-Type: image/jpeg
Date: Wed, 19 Mar 2025 19:53:31 GMT
Last-Modified: Wed, 19 Mar 2025 17:34:08 GMT
Server: OpenBSD httpd
Connection closed by foreign host.
$
@andros@twtxt.andros.dev your client is breaking things, I am afraid. This hash (ptxsca
), which you seem to be using to reply to @movq@www.uninformativ.de is not the right one.
@andros@twtxt.andros.dev Hm, looks correct to me. The image to be displayed is a thumbnail and this links to the full-sized image. The thumbnail (JPG) is auto-generated from the full image (PNG), hence the two extensions.
What does look strange, though, is that your client came up with the hash pqsmcka
, while it should have been te5quba
. đ€
@prologic@twtxt.net Can we add a table in twtxt.dev with features of each client?
- Is active?
- Extensions compatibility
- Language
- Multiaccount.
- Mutiuser
And so onâŠ
@movq@www.uninformativ.de The urls of the images are strange! My client crashes to display them, and when I tried some urls, I found a redirect. Ah! And the images had two extensions.
@eapl.me@eapl.me Good job! I have added these comments:
- It is only long for humans. Clients can only leave a hyperlink.
- The nickname is just a decoration, only the date that acts as the id and the URL matter. The nick is used for humans reading the feed.
- It can be migrated with a script, if the feed exists.
i have got to try the jenny yarn client it looks so fun and old schoolâŠâŠ..
well⊠it has been an opportunity to build an artisanal microblogging client on top of a minimalist protocol. I agree on the hacker toy part.
And of course itâs about being part of a niche community which is (mostly) amazing, and nurturing. As there is almost no one writing in my native spanish, it has been an interesting challenge to share my thoughts in english, as well.
I couldnât say itâs a âsocial networkâ per se, I think it lack many engagement things usually associated with social networks, although it has a social part of igniting discussions, learnings and behavioral changes, which is the meaning of social for me.
Are there any clients to read gemini?
I have released new updates to the twtxt.el client.
- New feature: Notifications.
- Updated: Improved user interface for new posts.
- Updated: Documentation.
- Updated: Some UI elements and included information about shortcuts in each buffer.
- Minor fixes.
Source code: https://codeberg.org/deadblackclover/twtxt-el
In the next version: You will be able to send direct messages.
Enjoy!
#emacs #twtxt #twtxtel
ah! those german calendars. Somehow I was thinking of something like mine, with spaces to write inside each day.
I worked for a german company and they gave away these calendars to our clients and team every year, but the model you can hang on the wall. Memory unlocked!
@prologic@twtxt.net If it develops, and Iâm not saying it will happen soon, perhaps Yarn could be connected as an additional node. Implementation would not be difficult for any client or software. It will not only be a backup of twtxt, but it will be the source for search, discovery and network health.
pls elaborate on a âp2p databaseâ, âall storyâ and âRegistriesâ.
My first thought takes me to something like secure-scuttlebutt
which itâs painful to sync data using clients, and too slow compared to downloading a text file.
Also Iâd like for twtxt to avoid becoming an ActivityPub. Works well but itâs uses too many resources IMO.
https://kingant.net/2025/02/mastodon-the-cost-of-running-my-own-server/
Iâm defending being able to self-host your Web client (like youâd do with a Wordpress, twtxt is a micrologging, at the end), instead of federated instances, so in a first thought Iâd say Registries have many disadvantages being the first one that someone has to maintain them active.
@prologic@twtxt.net make server actually because i donât need the client on my server, also i run make deps before just in case lol
You can find the #twtxt-el channel in Libera IRC to talk about the twtxt.el client, I will keep my connection open so you can ask me questions. Thank you!
Hacer software cĂłdigo opensource es desafiante y paulatinamente desgasta a su autor. Todo comienza con pasiĂłn y entusiasmo, por supuesto. Si logras repercusiĂłn, te enfrentas a una carrera de fondo que muchos terminan abandonando por las demandas constantes de usuarios que, a menudo, no valoran el trabajo ni contribuyen de manera significativa. Por mencionar un caso reciente: Hector Martin. LĂder del proyecto Asahi Linux, quien dedicĂł años a adaptar Linux para los procesadores Apple Silicon, un logro tĂ©cnico impresionante. Sin embargo, terminĂł renunciando debido a la presiĂłn de usuarios que exigĂan soporte y mejoras como si fueran clientes pagos.
La mayorĂa de los mantenedores no reciben ningĂșn soporte econĂłmico. Solo unos pocos proyectos logran sostenibilidad financiera a travĂ©s de patrocinios, mientras que la mayorĂa de los desarrolladores terminan con un segundo empleo no remunerado.
Sin un cambio en la forma en que se valora y apoya los proyectos Opensource, y no solo hablo de las grandes empresas multimillonarias. SerĂa una perdida para todos si acabaremos con un ecosistema de software archivado y abandonado.
Ahora te paso la pelota a ti, Âżcuando fue la Ășltima vez que apoyaste a un mantenedor de software opensource?
I have released new updates to the twtxt.el client.
- New feature: View and interact with threads.
- Optimisation of ordering for long feeds.
- Minor fixes.
In the next version you will be able to see all your mentions.
Enjoy!
@prologic@twtxt.net Damn! :-( Yeah, I wonât build that into my client. Not worth it for the many things that are still undetectable and the low frequency it happens.
looks good to me!
About aliceâs hash, using SHA256, I get 96473b4f
or 96473B4F
for the last 8 characters. Iâll add it as an implementation example.
The idea of including it besides the follow URL is to avoid calculating it every time we load the file (assuming the client did that correctly), and helps to track replies across the file with a simple search.
Also, watching your example Iâm thinking now that instead of {url=96473B4F,id=1}
which is ambiguous of which URL we are referring to, it could be something like:
{reply_to=[URL_HASH]_[TWT_ID]}
/ {reply_to=96473B4F_1}
That way, the âfull twt IDâ could be 96473B4F_1
.
Hey everyone!
About the idea of improving the âthreadâ extension, what if we set aside March 2025 to gather proposals and thoughts from everyone? We could then vote on them at the end of the month to see if the change and migration are worth it.
The voting could include client maintainers (and maybe even users too). That way, we get a good mix of perspectives before taking a decision in a decent timelapse.
What do you think? If this sounds good, we can start agreeing on this. Let me know your thoughts!
@lyse@lyse.isobeef.org Clients could detest edits đ€
@bmallred@staystrong.run I forgot one more effect of edits. If clients remember the read status of massages by hash, an edit will mark the updated message as unread again. To some degree that is even the right behavior, because the message was updated, so the user might want to have a look at the updated version. On the other hand, if itâs just a small typo fix, itâs maybe not worth to tell the user about. But the client doesnât know, at least not with additional logic.
Having said that, it appears that this only affects me personally, noone else. I donât know of any other client that saves read statuses. But donât worry about me, all good. Just keep doing what youâve done so far. I wanted to mention that only for the sake of completeness. :-)
@andros@twtxt.andros.dev I donât see a burst of new twtxt clients popping up. Yeah, the most recent ones are TwtxtReader and twtxt-el. Did I miss one? I agree with @david@collantes.us, looks normal to me. :-)
Iâm also working on my rewrite at the moment, but that started⊠*looking at the git history*⊠oh wow! O_o Over two years ago! I just implemented jumping to the next/previous unread message.
working on my bookmarks tool, I found out that http(s)://domain.tls
is not a valid resource, but http(s)://domain.tls/
is, as you can see here: https://stackoverflow.com/a/2581423
I suppose that internally the wget/curl or whatever client you are using is redirecting it?
@andros@twtxt.andros.dev, I am getting:
Feed was redirected: https://twtxt.andros.dev -> https://twtxt.andros.dev/
Each time my client fetches your feed. It just doesnât make any sense to me. Wouldnât be both, pretty much, be the same (I noticed the /
, yes)?
@andros@twtxt.andros.dev I wouldnât call it regular, but cyclical. Since, with the exception of Yarn (maybe?), clients are everything when it comes to twtxt, every now and then we see an increase of interest on new development. I have seeing them come and go, only few âbeside remainsâ. :-)
Question to the twtxt veterans, are we experiencing an explosion of clients or is this a regular occurrence?
I have released new updates to the twtxt.el client.
- Markdown to Org mode (you need to install Pandoc).
- Centred column.
- Added new logo.
- Added text helper.
The new version I will try to finish the visual thread. You still canât see the thread yet.
#emacs #twtxt #twtxtel
@aelaraji@aelaraji.com Can you give me examples of hashes that you have detected wrong between Emacs client and twtxt.net?
Perhaps there is some character, some space, that is creating the discrepancy.
@prologic@twtxt.net Agreed! But clients can hallucinate and generate wrong hashes
aka Lies
đ€Ł Also, If you chheck your own twt on twtxt.net, it looks like a root twt instead of a replay.
[ âł Reply to twt ]
button?
I donât think so, at least the tests I did passed. If youâre pretty sure itâs a bug, please create an issue in the repository with the specific case and Iâll investigate it.
There are 2 buttons to make replicas, one makes a replica in the thread where the twt is located (this is the one that should be used the most, as it serves a thread), the other creates a replica to a specific twt.
Iâll let you know a bit about the status: Iâm just now implementing the thread screen. There you can be sure where you are. Itâs a bit confusing right now, sorry. I think the client is still in alpha. When Iâve finished what Iâm doing, and the direct message system, Iâll freeze development and focus on creating more tests, looking for bugs and making small visual adjustments.
@arne@uplegger.eu Hi! I love that youâre implementing it! Maybe, when weâre both done, we could test the clients by communicating both.
I donât think Iâm going to be able to help you much, my knowledge of OpenSSL and PHP is not as high as Iâd like it to be.
Maybe the OpenSSL version uses SHA-1 by default in PHP. Or that the IV is derived together with the key (not generated separately). But Iâm not able to answer your questions, sorry.
Iâm invoking the commands directly, without any libraries in between. Maybe that would help you?
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.)
well, Gemini clients like Lagrange allow to show inline images when you click on an image link. Text based clients, like Amfora, usually allow to watch the image in another âwindowâ.
For example here: gemini://text.eapl.mx/en-making-a-tic-tac-toe-variant and there https://text.eapl.mx/en-making-a-tic-tac-toe-variant
I agree that some topics require images to make it easier to explain.
Bloody hell đ€Šââïžđ€Šââïž
$ jq -r --arg host "gopher.mills.io" '. | select(.request.host==$host) | "\(.request.client_ip) \(.request.uri) \(.request.headers["User-Agent"])"' mills.io.log-au | while IFS=$' ' read -r ip uri ua; do asn="$(geoip -a "$ip")"; echo "$asn $ip $uri $ua"; done | grep -E '^45102.*' | sort | head
45102 47.251.70.245 /gopher.floodgap.com/0/feeds/democracynow/2015/Oct/14/0 ["Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36"]
45102 47.251.84.25 /gopher.floodgap.com/0/feeds/voaheadlines/2014/Mar/09/voanews.com-content-article-1867433.html ["Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36"]
45102 47.82.10.106 /gopher.viste.fr/1/OnlineTools/hangman.cgi%3F0692937396569A52972EB2 ["Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36 Edg/114.0.1823.43"]
45102 47.82.10.106 /gopher.viste.fr/1/OnlineTools/hangman.cgi%3F9657307A96569A52974634 ["Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36 Edg/114.0.1823.43"]
45102 47.82.10.106 /gopher.viste.fr/1/OnlineTools/hangman.cgi%3FB7571C7896569A529E6603 ["Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36 Edg/114.0.1823.43"]
45102 47.82.10.106 /gopher.viste.fr/1/OnlineTools/hangman.cgi%3FB75EF81296569A529E6617 ["Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36 Edg/114.0.1823.43"]
45102 47.82.10.106 /gopher.viste.fr/1/OnlineTools/hangman.cgi%3FC6564ADB96569A5A9E660C ["Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36 Edg/114.0.1823.43"]
tt
rewrite in Go and quickly implemented a stack widget for tview. The builtin Pages is similar but way too complicated for my use case. I would have to specify a mandatory name and some additional options for each page. Also, it allows me to randomly jump around between pages using names, but only gives me direct access the first, however, not the last page. Weird. I don't wanna remember names. All I really need is a classic stack. You open a new fullscreen dialog and maybe another one on top of that. Closing the upper most brings you back to the previous one and so on.
Thinking about trying tt. If it really usable i will abandon twtxtdon (service to read twtxt feeds from mastodon client), which currently has only authorization implemented
@prologic@twtxt.net Of course you donât notice it when yarnd only shows at most the last n messages of a feed. As an example, check out mckinleyâs message from 2023-01-09T22:42:37Z. It has â[Scheduled][Scheduled][Scheduled]â⊠in it. This text in square brackets is repeated numerous times. If you search his feed for closing square bracket followed by an opening square bracket (][
) you will find a bunch more of these. It goes without question he never typed that in his feed. My client saves each twt hash Iâve explicitly marked read. A few days ago, I got plenty of apparently years old, yet suddenly unread messages. Each and every single one of them containing this repeated bracketed text thing. The only conclusion is that something messed up the feed again.
@eapl.me@eapl.me Yeah, you need some kind of storage for that. But chances are that thereâs already a cache in place. Ideally, the client remembers etags or last modified timestamps in order to reduce unnecessary network traffic when fetching feeds over HTTP(S).
A newsreader without read flags would be totally useless to me. But I also do not subscribe to fire hose feeds, so maybe thatâs a different story with these. I donât know.
To me, filtering read messages out and only showing new messages is the obvious solution. No need for notifications in my opinion.
There are different approaches with read flags. Personally, I like to explicitly mark messages read or unread. This way, I can think about something and easily come back later to reply. Of course, marking messages read could also happen automatically. All decent mail clients Iâve used in my life offered even more advanced features, like delayed automatic marking.
All I can say is that Iâm super happy with that for years. It works absolutely great for me. The only downside is that I see heaps of new, despite years old messages when a bug causes a feed to be incorrectly updated (https://twtxt.net/twt/tnsuifa). ;-)
thatâs a fair point.
Perhaps, since Twitter in 2006 never implemented read flags, every derivative microblogging system never saw that as an expected feature. This is curious because Twitter started with SMS, where on our phones we can mark messages as read or unread.
I think it all comes from the difference between reading an email (directed to you) vs. reading public posts (like a blog or a âwall,â where you donât mark posts as read). Itâs not necessary to mark it as âreadâ, you just jump over it.
Reading microblogging posts in an email program is not common, I think, and I havenât really used it, so I cannot say how it works, and whether it would be better for me or not.
However, Iâve used Thunderbird as a feed reader, and I understand the advantages when reading blog posts.
About read flags being simple, well⊠we just had a discussion this morning about how tracking read messages would require a lot of rethinking for clients such as timeline
where no state is stored. Even considering some kind of ânotification of unread messages or mentionsâ is not expected for those minimalist client, so itâs an interesting compromise to think about.
@eapl.me@eapl.me Read flags are so simple, yet powerful in my opinion. I really donât understand why this is not a thing in most twtxt clients. Itâs completely natural in e-mail programs and feed readers, but it hasnât made the jump over to this domain.
You write too much for my client đ
@andros@twtxt.andros.dev How about putting the whole encrypted conversation into a sperate twtxt-file. Just like the archive feature (?). That way, the general clients donât have to cope with the decrytption stuff and it wonât break the general public conversations.
@arne@uplegger.eu Klingt gut, Du darfst uns gern mal ein paar Bildschirmfotos vom aktuellen Stand zeigen. :-) Die erste Aufnahme sah bereits recht aufgerÀumt aus.
Ich mĂŒsste auch endlich mal an meinem Client weitermachen. Aber heut nimmer.
@prologic@twtxt.net @lyse@lyse.isobeef.org First, please leave me your comments on the repository! Even if itâs just to give your opinion on what shouldnât be included. The more variety, the better.
Second, Iâm going to try to do tests with Elliptic keys and base64. Thanks for the advice @eapl@eapl.me
Finally, Iâd like to give my opinion. Secure direct messages are a feature that ActivityPub and Mastodon donât have, to give an example. By including it as an extension, weâre already taking a significant leap forward from the competition. Does it make sense to include it in a public feed? In fact, weâre already doing that. When we reply to a user, mentioning them at the beginning of the message, itâs already a direct message. The message is within a thread, perhaps breaking the conversation. Direct messages would help isolate conversations between 2 users, as well as keeping a thread cleaner and maintaining privacy. I insist, itâs optional, it doesnât break compatibility with any client and implementing it isnât complex. If you donât like it, youâre free to not use it. If you donât have a public key, no one can send you direct messages.
another one would be to allow changing public keys over time (as it may be a good practice [0]
). A syntax like the following could help to know what public key you used to encrypt the message, and which private key the client should use to decrypt it:
!<nick url> <encrypted_message> <public_key_hash_7_chars>
Also Iâd remove support for storing the message as hex, only allowing base64 (more compact, aiming for a minimalistic spec, etc.)
@arne@uplegger.eu nice work with the client.
I also see you are using the Yellow CMS for your websiteđ
@arne@uplegger.eu Uuhhhh, more twtxt clients, very nice! :-)
@sorenpeter@darch.dk Yes it works, thx: https://doesnm.cc/mentions.txt . Iâm deleted html tags because my client do not support html rendering
@<url>
form of mentions. Strictly require that all mentions include a nickname/name; i.e: @<name url>
.
@prologic@twtxt.net I say we should find a way to support mentions with only url, no nick, as per the original spec.
- For
@<nick url>
we already got support
- For
@<nick>
the posting client should expand it to@<nick url>
, if not then the reading client should just render it as@nick
with no link.
- For
@<url>
the sending client should try to expand it to@<nick url>
, if not then the reading client should try to find or construct a nick base on:
- Look in twtxt.txt for a
nick =
- Use (sub)domain from URL
- Use folder or file name from URL
- Look in twtxt.txt for a