Printi, 360imprimir, Rei do Sticker?
(no Brasil)
captura de tela do Reclame Aqui do Rei do Sticker
Printi, 360imprimir, Rei do Sticker?
(no Brasil)
captura de tela do Reclame Aqui do Rei do Sticker
/ME flips a bird to life
So, I've been working on 2 main twtxt-related projects.
The first is small Node / express application that serves up a twtxt file while allowing its owner to add twts to it (or edit it outright), and I've been testing it on my site since the night I made that post. It's still very much an MVP, and I've been intermittently adding features, improving security, and streamlining the code, with an eye to release it after I get an MVP done of project #2 (the reader).
But that's where I've been struggling. The idea _seems_ simple enough - another Node / express app (this one with a Vite-powered front-end) that reads a public twtxt file, parses the "follow" list, grabs (and parses) _those_ twtxt files, and then creates a river of twts out of the result. The pieces work fine in seclusion (and with dummy data), but I keep running into weird issues when reading real-live twtxt files, so some twts come through, while others get lost in the ether. I'll figure it out eventually, but for now, I've been spending far more time than I anticipated just trying to get it to work end-to-end.
On top of it, the 2 projects wound up turning into 4 (so far), as I've been spinning out little libraries to use across both apps (like https://jsr.io/@itsericwoodward/fluent-dom-esm, and a forthcoming twtxt helper library).
In the end, I'm hoping to have project 1 (the editor) into beta by the end of October, and project 2 (the reader) into beta sometime after that, but we'll see.
I hope this has satisfied your curiosity, but if you'd like to know more, please reach out!
Press play to hear from Marina Zurkow & James Schmitz [@hx2A@mastodon.art] the artists behind ‘The River is a Circle (Times Square Edition)’ - September’s #MidnightMoment, a visual “combination of live data and a matrix of researched information about the Hudson River ecology,” says Zurkow.»
https://www.instagram.com/reel/DO6jbXrEdBG
#CreativeCoding #Processing #Python #py5 #TimesSquare #NYC
Press play to hear from Marina Zurkow & James Schmitz [@hx2A@mastodon.art] the artists behind ‘The River is a Circle (Times Square Edition)’ - September’s #MidnightMoment, a visual “combination of live data and a matrix of researched information about the Hudson River ecology,” says Zurkow.»
https://www.instagram.com/reel/DO6jbXrEdBG
#CreativeCoding #py5 #TimesSquare #NYC
The single plum that my plum tree gave us in 2025.
The single plum that my plum tree gave us in 2025.
The single plum that my plum tree gave us in 2025.
In here it is all about control, and money.
I just got my renewed documents. Their expiration date says something like 01.09.40. Huh? That looks super weird to me, like an error. But no, it’s 2040 … Just 15 years away.
I just got my renewed documents. Their expiration date says something like 01.09.40. Huh? That looks super weird to me, like an error. But no, it’s 2040 … Just 15 years away.
Páginas da revista sobre a Noite de Processing no Garoa Hacker Clube
https://www.catarse.me/variavel (para o Brasil)
https://www.indiegogo.com/projects/variavel-magazine (para outros países)
#ProgramaçãoCriativa #CreativeCoding
Reprodução de páginas da revista onde aparecem alguns dos meus desenhos e o começo da entrevista.
The thread is defined by two parts:
1. The hash
2. The subject
The client/pod generate the *hash* and index it in it's database/cache, then it simply query the subject of other posts to find the related posts, right?
In my own client current implementation (using hashes), the only calculation is in the hash generation, the rest is a verbatim copy of the subject (minus the
# character), if this is the common implemented approach then adding the location based one is somewhat simple.s
function setPostIndex(post) {
// Current hash approach
const hash = createHash(post.url, post.timestamp, post.content);
// New location approach
const location = post.url + '#' + post.timestamp;
// Unchanged (probably)
const subject = post.subject;
// Index them all
addToIndex(hash, post);
addToIndex(location, post);
addToIndex(subject, post);
}
// Both should work if the index contains both versions
getThreadBySubject('#abcdef') => [post1, post2, post3]; // Hash
getThreadBySubject('https://example.com#2025-01-01T12:00:00') => [post1, post2, post3]; // Location
As I said before, the mention is already location based
@<example https://example.com/twtxt.txt>, so I think we should keep that in consideration.Of course this will lead to a bit of fragmentation (without merging the two) but I think this can make everyone happy.
Otherwise, the only other solution I can think of is a different approach where the value doesn't matter, allowing to use anything as a reference (hash, location, git commit) for greater flexibility and freedom of implementation (this probably need the use of a fixed "header" for each post, but it can be seen as a separate extension).
I want us to preserve Content based addressing.
Let's improve the user experience and fix the hash commission problems.
) ...
(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.
https://movq.de/v/3f9fc6ebdd/equinox.png
(Instead of this or this.)
https://movq.de/v/3f9fc6ebdd/equinox.png
(Instead of this or this.)
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!✌️
1. Link rot & migrations: domain changes, path reshuffles, CDN/mirror use, or moving from txt → jsonfeed will orphan replies unless every reader implements perfect 301/410 history, which they won’t.
1. Duplication & forks: mirrors/relays produce multiple valid locations for the same post; readers see several “parents” and split the thread.
1. Verification & spam-resistance: content addressing lets you dedupe and verify you’re pointing at exactly the post you meant (hash matches bytes). Location anchors can be replayed or spoofed more easily unless you add signing and canonicalization.
1. Offline/cached reading: without the original URL being reachable, readers can’t resolve anchors; with hashes they can match against local caches/archives.
1. Ecosystem churn: all existing clients, archives, and tools that assume content-derived IDs need migrations, mapping layers, and fallback logic. Expect long-lived threads to fracture across implementations.
> With content-addressed threading, a reply points at something that’s intrinsically identified (hash of author/feed URI + timestamp + content). That ID never changes as long as the content doesn’t. Switching to location-based anchors makes the reply target extrinsic—it now depends on where the post currently lives. In a pull-based, decentralised network, locations drift. The moment they do, thread identity fragments.
#<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
#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
#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
https://www.youtube.com/live/XoQipHFMZVU
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.