Searching We.Love.Privacy.Club

Twts matching #Twt
Sort by: Newest, Oldest, Most Relevant
prologic
twtxt.net
 (2w ago)
↳ 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
lyse
lyse.isobeef.org
 (5w ago)

@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