(WTF, asciiworld-sat-track somehow broke, but I have not changed any of the scripts at all. O_o It doesn't find the asciiworld-sat-calc anymore. How in the world!? When I use an absolute path, the .tle is empty and I get a parsing error. Gotta debug this.)
1. 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.
2. 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.
3. 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?
4. 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.
5. 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. :-)
It looks amazing from the map, you probably can't tell even by looking from space.
Hoje abriram as inscrições para os tutoriais, grátis, vagas limitadas!
(Aproveite e avise aquele seu amigo gringo que ele pode comprar um ingresso de estudante doação para alguém que não poderia participar do evento completo com as palestras! :D)
https://pybr2025.eventbrite.com.br/
#Python
1. The current hash relies on a
url field too, by specification, it will use the first # url = <URL> in the feed's metadata if present, that too can be different from the fetching source, if that field changes it would break the existing hashes too, a better solution would be to use a non-URL key like # feed_id = <UNIQUE_RANDOM_STRING> with the url as fallback.2. We can prevent duplications if the reference uses that same url field too or the client "collapse" any reference of all the urls defined in the metadata.
3. I agree that hashing based on content is good, but we still use the URL as part of the hashing, which is just a field in the feed, easily replicable by a bot, also noting that edits can also break the hash, for this issue an alternative solution (E.g. a private key not included in the feed) should be considered.
4. For offline reading the source would be downloaded already, the fetching of non followed feeds would fill the gap in the same way mentions does, maybe I'm missing some context on this one.
5. To prevent collisions there was a discussion on extending the hash (forgot if that was already fixed or not), but without a fallback that would break existing clients too, we should think of a parallel format that maintains current implementations unchanged, we are already backward compatible with the original that don't use threads at all, a mention style format for that could be even more user-friendly for those clients.
We should also keep in mind that the current mention format is already location based (
@<example https://example.com/twtxt.txt>) so I'm not that worried about threads working the same way.Hope to see some other thought about this matter. 🤓
Looking forward to it!✌️
#<https://example.com/twtxt.txt#2025-09-22T06:45Z> with the timestamp in an anchor link. the need for a mention is avoided like this as well since it's already linking to the replied-to feed!🐀💭 i should just implement it into bbycll and force it into existence
https://www.youtube.com/watch?v=yXTDslxVfdM&list=PLLIPpKeh9v3ZFEHvNd5xqUrCkqLgXnekL
«Graciliano Ramos: Quem adulterou as memórias do escritor?
“Memórias do Cárcere” tinha diferença entre manuscritos do autor e edições publicadas em livro»
https://archive.ph/UuIQw
#GracilianoRamos #LiteraturaBrasileira
#Portugal #Palestine #recognition
Screenshot of https://en.m.wikipedia.org/w/index.php?title=International_recognition_of_Palestine&diff=prev&oldid=1312606019&diffonly=1 where we can see a change to an wikipedia page, adding Portugal to the list of countries that recognize Palestine
https://www.youtube.com/live/XoQipHFMZVU
No wonder I think I've heard this is one of the things that distinguishes professional software development from [my preferred domain of] things such as "end-user programming" etc.
The problem is that when you start sharing code in the context of a FLOSS project you almost immediately get enmeshed in concerns about packaging and how other people will install stuff, when sometimes you just don't want to be a professional software developer! 😿
I'm always borrowing terms (learning ideas) from @lr like: *incidental complexity*. I hate *incidental complexity* or maybe I just fear *incidental complexity*. Can we escape *incidental complexity*? I guess not.
After seeing so many resolutions, I think you're only missing a *matrioska* version of it. 🪆
The order of
SOURCE > POST does make more sense indeed.
BTW, the feed on https://feeds.twtxt.net/ seem down? It says it's in maintenance.
https://arstechnica.com/science/2025/09/meet-the-2025-ig-nobel-prize-winners/
...também conta que os nenês curtem o leita materno quando a mãe comeu alho.
https://arstechnica.com/science/2025/09/meet-the-2025-ig-nobel-prize-winners/
...também conta que os nenês curtem o leite materno quando a mãe comeu alho.
https://arstechnica.com/science/2025/09/meet-the-2025-ig-nobel-prize-winners/
Mate in 5 I think... :)
#chess #ChessPuzzle #lichess
If you want to learn more about it, why not see this video with its founder?
@dff@dff https://videos.trom.tf/w/gVBnrHUypajuZkVKrafwz4
Like this: https://www.linkedin.com/posts/paulwaynewalter_urban-gis-people-great-free-self-paced-activity-7373022072685506560-z0S5
«Oh, also, here is a link to Transitland's map of open #GTFS data: https://www.transit.land/map#3.5/40.41/-104.84»
Like this: https://www.linkedin.com/posts/paulwaynewalter_urban-gis-people-great-free-self-paced-activity-7373022072685506560-z0S5
Geo-Python and Automating GIS Processes (‘#AutoGIS’) have been developed by the Department of Geosciences and Geography at the University of Helsinki, Finland. The course has been planned and organized by the #DigitalGeographyLab. The teaching materials are openly accessible for anyone interested in learning.»
https://autogis-site.readthedocs.io/en/latest/
(via Paul Walter no linkedin)
#GIS #geoPython #geopandas #shapely #osmnx #networkx
Geo-Python and Automating GIS Processes (‘#AutoGIS’) have been developed by the Department of Geosciences and Geography at the University of Helsinki, Finland. The course has been planned and organized by the #DigitalGeographyLab. The teaching materials are openly accessible for anyone interested in learning.»
https://autogis-site.readthedocs.io/en/latest/
#GIS #geoPython #geopandas #shapely #osmnx #networkx
https://www12.senado.leg.br/ecidadania/visualizacaomateria?id=160575
Precisa logar com gov.br e tal, mas acho que vale a pena votar para mandar uma mensagem, a diferença andou diminuindo :-S
I called it a day, yes. \o/
Enjoy your weekend! (I hope, you just called it a day and don't have to drive to the office or silly shenanigans like that.)
Now guess what manufacturers are pushing for ...
Now guess who couldn't complete a task at work this Saturday morning, because a certain cloud service was down ...
IT is fucked. Throw it all away and start over.
https://cbers4asat.readthedocs.io/pt-br/latest/
cc @elmoneto@elmoneto (você viu isso? eu não manjo nada mas já fiquei animado...)
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.
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
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 ]