Mastodon ⌘ Read more****
Shuffle. Jam. Repeat.
display_name is worthwhile, since nick is functionally a display name
mentioning http://darch.dk/testing-syndication-via-rss-to-social-media-via-bufffer
(IP: 34.96.47.28)
But you can create and register your own conversion functions too!
https://py5coding.org/integrations/custom_integrations.html
Dormir no me va a quitar la ansiedad, pero al menos sería estar unas horitas haciendo la desconexión. ⌘ Read more****
> Aachen has been officially certified as "Bad Aachen", but for alphabetical reasons usually declines to use the prefix
>
> — https://en.wikipedia.org/wiki/List_of_spa_towns_in_Germany#A
That made me chuckle.
Pues hoy por fin, a las 16 semanas, tamagochi se me ha dormido en los brazos 🥰🥰😅 (es que es duro de pelar el joio)
#bonanit ⌘ Read more****
Sorry, this pun only works in German, where "Bad" means spa and is used as prefix for spa towns.
Relevant film: https://www.youtube.com/watch?v=YYNbSuMLZZg
> Waste paper, like an opened envelope, suits a shopping list perfectly fine.
Indeed, I’m drowning in this stuff and I throw it away anyway, so I might just use it.
> You've got a nice handwriting, I like it.
Thanks. 😅 (It used to be horrible. Gosh, the teachers scolding me in school … Bah. 😂)
> Waste paper, like an opened envelope, suits a shopping list perfectly fine.
Indeed, I’m drowning in this stuff and I throw it away anyway, so I might just use it.
> You've got a nice handwriting, I like it.
Thanks. 😅 (It used to be horrible. Gosh, the teachers scolding me in school … Bah. 😂)
Ahora en el bus cuando vea a alguien sonriéndole al móvil voy a pensar que a lo mejor está hablando con chatgpt. ⌘ Read more****
My hardware collection also includes a few brass-like looking screws that I could repurpose into rivets. But I reckon I have to upgrade my burner first. I'm not a metal worker by any means, so I could be totally wrong, but I imagine that some heat is necessary to loosen the work-hardening effect when beating on them. I will do some experiments on Saturday and report back.
I have a friend that might lock himself out of his home if there's a power outage while I keep removing apps and devices from my daily lives instead.
I recently switched from all the todo apps I used to sticky notes on my monitors and a pocket notebook for sketching and quick notes.
It reminds me of the monsters in Heart of Darkness on PSX (just replayed the other day).
https://www.youtube.com/shorts/ZnGOpT5NKxc
>
> now, normal people buy smart toasters & coffee mugs while every techie I know is on the verge of retreating to the forest
https://plush.city/@JellyTBeagle/115272072725713725
>
> now, normal people buy smart toasters & coffee mugs while every techie I know is on the verge of retreating to the forest
https://plush.city/@JellyTBeagle/115272072725713725
Y el buque que había enviado el perro al final de postureo. Puto pesoe siempre y con la fuerza de mil mares. ⌘ Read more****
https://www.youtube.com/watch?v=zL831kQUbEo
Foto do single "Yes Sir, I Can Boogie" das Baccara a tocar, com a capa à mostra. Pela capa consegue-se ver que o lado B tem a música "Cara mia". A capa propriamente dita são as duas cantoras vestidas com o que se calhar são camisas de dormir, uma de preto e a outra de branco. Uma delas segura uma rosa. A edição é da RCA Victor.
https://www.youtube.com/watch?v=zL831kQUbEo
Foto do single "Yes Sir, I Can Boogie" das Baccara a tocar, com a capa à mostra. Pela capa consegue-se ver que o lado B tem a música "Cara mia". A capa propriamente dita são as duas cantoras vestidas com o que se calhar são camisas de dormir, uma de preto e a outra de branco. Uma delas segura uma rosa. A edição é da RCA Victor.
https://www.youtube.com/watch?v=zL831kQUbEo
Foto do single "Yes Sir, I Can Boogie" das Baccara a tocar, com a capa à mostra. Pela capa consegue-se ver que o lado B tem a música "Cara mia". A capa propriamente dita são as duas cantoras vestidas com o que se calhar são camisas de dormir, uma de preto e a outra de branco. Uma delas segura uma rosa. A edição é da RCA Victor.
Not all medecos pero siempre un putísimo medeco. ⌘ Read more****
Pues en Italia ya se han planteado una huelga general por lo de la flotilla ⌘ Read more****
mentioning http://darch.dk/testing-syndication-via-rss-to-social-media-via-bufffer
(IP: 34.96.45.23)
mentioning http://darch.dk/testing-syndication-via-rss-to-social-media-via-bufffer
(IP: 34.96.45.23)
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 to nick if not defined-
banner: Using the same format as avatar but the image expected is wider, inspired by other socials aroundI 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! 🤞
The client must reference both properly or it would miss posts, including both this way is a bit pointless if you can't use the hash or url separately.
Being a highly likely a breaking change anyway I think @zvava proposal looks much better.
https://movq.de/v/f48c7cda09/IMG_20251001_200317.jpg.jpg
https://movq.de/v/f48c7cda09/IMG_20251001_202438.jpg.jpg
https://movq.de/v/f48c7cda09/IMG_20251001_200317.jpg.jpg
https://movq.de/v/f48c7cda09/IMG_20251001_202438.jpg.jpg
#<https://example.com/tw.txt#yyyy-mm-ddThh:mm:ssZ> is foolproof)
@<...> being mentions
Lizard or shark or something
>
(#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 addressingI like that property (an off-ramp to location-based addressing), so I think I could live with that approach. ✅
(I’m not sure why we’re using text fragments, though. Wouldn’t that link to the first occurence of
2025-10-01T10:28:00Z? That’s not necessarily correct. And, to be proper URLs that Firefox and Chromium understand, it would also need to be written as 2025%2D10%2D01T10:28:00Z. The dash carries meaning, sadly. I think all this just creates needless complication. How about we just go with https://example.com/tw.txt#2025-10-01T10:28:00Z?)
>
(#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 addressingI like that property (an off-ramp to location-based addressing), so I think I could live with that approach. ✅
(I’m not sure why we’re using text fragments, though. Wouldn’t that link to the first occurence of
2025-10-01T10:28:00Z? That’s not necessarily correct. And, to be proper URLs that Firefox and Chromium understand, it would also need to be written as 2025%2D10%2D01T10:28:00Z. The dash carries meaning, sadly. I think all this just creates needless complication. How about we just go with https://example.com/tw.txt#2025-10-01T10:28:00Z?)
18:16 <aelaraji> quark 🙏 much appreciated but it won't be necessary, since there isn't much to miss out on in most of where I hang out, so I could just disconnect and spare everyone else the noise
18:17 *** aelaraji (aelaraji@776014f5a3edd32f1ed19658b7b85c8c655945b0feacaedd92fe60e61a3c0ae2) has quit (/ME goes "yeeeeet..!")
18:18 <quark> No noise for me.
18:18 <quark> It’s all good.
18:18 <quark> What would IRC be without on/offs?
18:19 <quark> Preeeety boring!
18:19 <quark> Ah, he was gone.
18:19 <quark> Well, I will twtxt this to him. LOL.
url field it finds. If there is none, it uses the URL that I’m using for fetching the feed.No validation, no logging.
In practice, I’ve not seen issues with people messing with this field. (What I do see, of course, is broken threads when people do legitimate edits that change the hash.)
I don’t see a way how anyone can impersonate anybody else this way. 🤔 Sure, you could use my URL in your
url field, but then what? You will still show up as zvava in my client or, if you also change your nick field, as movq (zvava).
url field it finds. If there is none, it uses the URL that I’m using for fetching the feed.No validation, no logging.
In practice, I’ve not seen issues with people messing with this field. (What I do see, of course, is broken threads when people do legitimate edits that change the hash.)
I don’t see a way how anyone can impersonate anybody else this way. 🤔 Sure, you could use my URL in your
url field, but then what? You will still show up as zvava in my client or, if you also change your nick field, as movq (zvava).
url to be used for hashing. No matter if it points to a different feed or whatever. Just unsubscribe from malicious feeds and you're done.Since the first
url is used for hashing, it must never change. Otherwise, it will break threading, as you already noticed. If your feed moves and you wanna keep the old messages in the same new feed, you still have to point to the old url location and keep that forever. But you can add more urls. As I said several times in the past, in hindsight, using the first url was a big mistake. It would have been much better, if the last encountered url were used for hashing onwards. This way, feed moves would be relatively straightforward. However, that ship has sailed. Luckily, feeds typically don't relocate.
Sois la leche, os gusta más la idea de mi madre haciendo de castañera que hayamos conseguido una relatoria de la ONU ⌘ Read more****
En Star Trek, cuando viajan a nuestra era no usan Google como navegador sino DuckDuckGo.
Star Trek New Horizon. T2E3 ⌘ Read more****
Mira, me ha llamado mi madre contándome una buena historia.
Le han llamado del colegio del pueblo para que se disfrace de castañera y vaya a contarles historias a les niñes.
Les ha dicho que sí, pero que hablará de bellotas, que no hay castañas en la zona.
Está ilusionada, haciendo el mandil, buscando los cucuruchos y las trébedes.
Es muy ilusionante, porque este año iba a cerrar el colegio por falta de niñes. Y gracias a dos familias migrantes se ha mantenido abierto. ⌘ Read more****
(#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)
Handling it via the pod might work but I think it's not the best approach, external feeds and clients don't usually use a pod api but their own implementation, so any workaround won't work there.
That's why my proposals addressed those issues:
- the idea of using a "key" instead of the
url (with the url as a fallback), the key could even be a public key so it can be used verifieable in crypto functions- using the timestamp to prevent content changes to break threads (plus being simpler to implement)
- using an explicit thread reference with an alternative subject format (like
[#THREAD_ID] Hello world and replies with (#REPLY_ID) Ahoy) so the content can change without affecting the thread reference, and anyone can use their own schemes freely
The eye candy is always good to have.
cors-anywhere via docker in a minute and it would work the same.Still, I could write one with just a dozen lines of Go or Node.js, I might consider writing one after the client is working decently.