Well, OK... why do I want an holopin account, anyway? Let me just delete my account, and get done with it. Profile, Account settings, Deleting personal data... "To request account deletion, please email support@holopin.io." WTF, seriously? It's 2025!
Mail sent.
Não podes ir todos os dias? Não tem mal, algumas das pistas estão a ser transmitidas online, em https://festa2025.softwarelivre.eu/streaming/
#FSL25 #SFD2025
[EN] Some of the talks (especially in the Drupal track) are in English, so you might interest to join us, from today till Sunday, either physically (Porto, Portugal) or following the streaming!
https://masto.pt/@FestaSoftwareLivre/115309542563016056
banner would) for clients having no knowledge of it.
display_name will be redundant, and add to the "busy" factor. That is, the opposite of simplicity.
I know about VS Codium... also, I'm struggling to move my stuff out of GitHub.
display_name is worthwhile, since nick is functionally a display name
But you can create and register your own conversion functions too!
https://py5coding.org/integrations/custom_integrations.html
> 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.
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
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
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.
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://example.com/tw.txt#yyyy-mm-ddThh:mm:ssZ> is foolproof)
@<...> being mentions
Lizard or shark or something
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 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.
(#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.
Há 33 anos atrás, ainda era a Internet Portuguesa uma criança, nasceu o primeiro #Talker Português, uma comunidade virtual que, 33 anos depois, continua activa.
Parabéns, #SelvaVirtual !
https://selva.grogue.org
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?and if the first
url metadata field changes, should it be logged with a time so we can still calculate hashes for old posts? or should it never be updated? (in the case of a pod, where the end user has no choice in how such events are treated) or do we redirect all the old hashes to the new ones (probably this, since it would be helpful for edits too)
Using a copper wire or a similarly malleable material, pass it through a drilled hole, hammer it on one end until flat, then do the same on the other side.
It does the same job of a rivet but it's flatter and look nicer on both sides, it's of course weaker but still strong enough for small objects.
It's sometimes used to reduce risk of deformities due to heat in hand-crafted jewelry and to reduce costs of small tools.
Giving the user multiple choices to do the same things is what is great about protocols in general.
I too had the same issue being a browser-based request, so the only solution is using a proxy.
For testing (and real personal use) I rely on this one https://corsproxy.io/.
In my client, I first check if the source allows me to fetch it without issues first and fallback to prefixing with a proxy if it gives an error.
For security reasons the client don't give you a readable error for CORS, so you must use a catch-all for that, if it fails again with the proxy you can deal with any other errors it throws as you normally would (preferably outside of the fetch function).
After the fetching responded, I store the
response.url value to fetch it again for updates without having to do extra calls (you can store it verbatim or as a flag to be able to change the proxy later).Here an extract of my code:
t
export async function fetchWithProxy(url, proxy=null) {
return await fetch(url).catch(err => {
if (!proxy) throw err;
return fetch(`${proxy}${encodeURIComponent(url)}`);
});
}
// Using it with
const res = await fetchWithProxy('https://twtxt.net/user/zvava/twtxt.txt', 'https://corsproxy.io/?');
// Get the working url (direct or through proxy)
const fetchingURL = res.url;
// Get the twtxt feed content (or handle errors)
const text = await res.text();
I also plan to allow the user to define a custom proxy field, I like the solution used by Delta.chat in their android app, where you can define the URL format with a variable
https://my-proxy?$TWTXT_URL since it allows you to define with more freedom any proxy without a prefix format.If the idea of using a third-party proxy is not to the user liking they can use a self-hosted solution like
cors-anywhere or build their own (with twtxt it should just be a GET).
Collection of purple poppy seeds and two of the pods they came from. The seeds are in a labeled packet with the date, useful for when we decide to plant them
#OpenStreetMap #FreeMaps #MapCarta
Access-Control-Allow-Origin header, so i just jumped into building a backend instead. did you find away around this limitation? :o
Em outubro vou dar este curso quintas à tarde com 4 encontros:
https://www.sescsp.org.br/programacao/ilustracoes-vetoriais-para-grandes-formatos-com-programacao/
#SescSP #TecnologiasEArtes
Captura de tela da página do curso no site do Sesc
I decided against blind rivets, because they leave ugly looking and sharp backsides, which can also interfer with the contents of the box. However, they would be an easy solution to make the corners more rigid and prevent any movement from the short sides.
Unfortunately, I can't weld or solder, so that's not an option. It would be the by far best solution. I wanna learn it one day, though.
Yes, Ken is a really great dude. He's the reason I gave this a shot in the first place. :-)
I can confirm, the
User-Agent header appears to be fixed. \o/Two other things I noticed, though:
1. There's now an
OPTIONS request for my feed coming from something that claims to be Firefox, pointing to your feed URL in the query. No clue what this is about. In any case, it's rejected with a 405 Method Not Allowed.2. Not that these few requests bother me at all, but you might wanna implement caching next with either the
If-Modified-Since or If-None-Match request headers. This way, if the feed hasn't changed, the web server can reply with a 304 Not Modified and no body at all, saving unnecessary traffic. But again, this is really not an issue for me at all. I just wanted to make sure you're aware of it, that's all. It might be even already on your agenda. Or you might decide to never do anything about it, which is also fine for me. :-)
No entanto, muitos nutrem uma tóxica noção de superioridade em relação aos pedestres: furam a sinalização, cruzam de qualquer jeito a faixa de pedestre, assustam a gente e tiram finas. É detestável isso.
Não seja ciclista com a mente carrocrata.
BTW - I promise, I intended it to be pronounced like "TweetStream" (or as written, "TwtStrm"), rather than "TweetStorm". Sorry again. 😊
After another round of coding this weekend, I'm happy to report that it now renders _all_ the twts (with markdown parsing), complete with
localstorage and server-based file caching.