Searching We.Love.Privacy.Club

Twts matching #Twt
Sort by: Newest, Oldest, Most Relevant
In-reply-to » Apologies to anyone who's seen an uptick in twtxt pings from me today... I've been working on shoe-horning my twtxt reader (TwtStrm) into my editor (TwtKpr, aka the express-twtkpr npm library), and it kind ran amok a few times. So again, sorry - I've added a minimum 10-minute cool-down period between pulls which should help (I hope 🙂).

@prologic@twtxt.net @bender@twtxt.net Thanks! Yeah, it already supports Twt Hash via twtxt-lib (both v1 and v2, when the time is right), plus most of the other features (multiline, user-agent, and metadata), and I’m working on (re-)implementing threading, mentions, and hash filtering (to make conversations easier to follow).

Here’s a current snapshot of my local version, in case anyone is interested:

Image

⤋ Read More
In-reply-to » Apologies to anyone who's seen an uptick in twtxt pings from me today... I've been working on shoe-horning my twtxt reader (TwtStrm) into my editor (TwtKpr, aka the express-twtkpr npm library), and it kind ran amok a few times. So again, sorry - I've added a minimum 10-minute cool-down period between pulls which should help (I hope 🙂).

@itsericwoodward@itsericwoodward.com Excited to see twtxt tooling in the Node ecosystem! Any plans to implement the Twtxt v2 extensions? Things like Twt Hash + Subject (proper threading), Multiline, etc. — all documented at https://twtxt.dev 👀

⤋ Read More
In-reply-to » Last year, I made a huge mistake. I repeated on here, what multiple sourcea at Google told me, and what is to this day, written on their blog about Android. I failed to take into consideration, that people who work at Google, often just lie, or present things intentionally vaguely, so they do not have to follow through with their promises. I would like to apologize to everyone, who took my previous posts here, as assurance software not explicitly approved by Google, will continue working on Android, past this year (or even just a couple months from now) and that everything has been resolved, as things are now in fact even worse, than they were before. To follow the current state of "Open Android", please check: https://keepandroidopen.org/

@thecanine@twtxt.net are you referring to the “WE FUCKING WON!” twtxt?

⤋ Read More
In-reply-to » @bender Fixed 🤣 Nobody was following that feed 😅 yarnd had no reason to "pull" it in.

@bender@twtxt.net Only missing roots would trigger that kind of sync IIRC. And that only works if another peering pod has the root twt. What you’re remembering, possibly, is an attempt to do what you were thinking of… But I tried it, turned out to be too expensive of an operation to do auotmatically.

⤋ Read More

@zvava@twtxt.net By hashing definition, if you edit your message, it simply becomes a new message. It’s just not the same message anymore. At least from a technical point of view. As a human, personally I disagree, but that’s what I’m stuck with. There’s no reliable way to detect and “correct” for that.

Storing the hash in your database doesn’t prevent you from switching to another hashing implementation later on. As of now, message creation timestamps earlier than some magical point in time use twt hash v1, messages on or after that magical timestamp use twt hash v2. So, a message either has a v1 or a v2 hash, but not both. At least one of them is never meaningful.

Once you “upgrade” your database schema, you can check for stored messages from the future which should have been hashed using v2, but were actually v1-hashed and simply fix them.

If there will ever be another addressing scheme, you could reuse the existing hash column if it supersedes the v1/v2 hashes. Otherwise, a new column might be useful, or perhaps no column at all (looking at location-based addressing or how it was called). The old v1/v2 hashes are still needed for all past conversation trees.

In my opinion, always recalculating the hashes is a big waste of time and energy. But if it serves you well, then go for it.

⤋ Read More