**Hmmm there’s a bug somewhere in the way I’m ingesting archived feeds 🤔

sqlite> select * from twts where content like 'The web is such ga ...**
Hmmm there’s a bug somewhere in the way I’m ingesting archived feeds 🤔

sqlite> select * from twts where content like ‘The web is such garbage these days%’;

  hash = 37sjhla

feed_url = https://twtxt.net/user/prologic/twtxt.txt/1
content = The web is such garbage these days 😔 Or is it the garbage search engines? 🤔
created = 2024-11-14T01:53:46Z
created_dt = 2024-11-14 01:53:46
… ⌘ Read more

Some A hole has been trying to pull every single Twtxt feed that existed/still exists since forever. How do I know? Welp’ They’ve been querying my Timeline™ instance for all of it, every single twtxt file and twt Hash they can find. 😆🤦 It must have been going on for days and I have just noticed… + it’s all coming from the same ASN AS136907 HWCLOUDS-AS-AP HUAWEI CLOUDS

Thank you Huawei for the DDos you sons of Glitches!!!

@quark@ferengi.one No editing old Twts that are the root of a thread with replies in the ecosystem. Just results in a fork. Unless the client has an implementation that does not store Twts keyed by Hash.

(#mkhkhuq) @quark@quark No editing old Twts that are the root of a thread with replies in the ecosystem. Just results in a fork. Unless th …
@quark @ferengi.one No editing old Twts that are the root of a thread with replies in the ecosystem. Just results in a fork. Unless the client has an implementation that does not store Twts keyed by Hash. ⌘ Read more

Ha! I stand corrected, didn’t scrolled long enough. Indeed, it should be added (you will need an account on Mills’ Gitea), noted.

@eaplme@eapl.me you wrote:

“That PHP snippet could be merged into https://twtxt.dev/exts/twt-hash.html”

Why, though? AFAIK @andros@twtxt.andros.dev’s client is on Emacs, @lyse@lyse.isobeef.org’s is on Python (and Golang, for tt2), @movq@www.uninformativ.de’s is on Python, and @prologic@twtxt.net’s is on Golang. All the client creator needs to know is in the documentation already, coding language agnostic.

just a note that we are doing that on PHP: https://github.com/eapl-gemugami/twtxt-php/blob/master/docs/03-hash-extension.md#php-72

That PHP snippet could be merged into https://twtxt.dev/exts/twt-hash.html

@david@collantes.us @andros@twtxt.andros.dev The correct hash would be si4er3q. See https://twtxt.dev/exts/twt-hash.html, a timezone offset of +00:00 or -00:00 must be replaced by Z.

(That said, there’s a bug in jenny as well. It only replaces +00:00, not -00:00. 🤡)

@prologic@twtxt.net @bender@twtxt.net

What is the hash of the last message from?: https://aelaraji.com/twtxt.txt

@bender@twtxt.net @aelaraji@aelaraji.com The client should ignore twts if it’s not compatible or not addressed to me. it’s a simple regex to add! It’s similar to Twt Hash Extension, should they be in another file? They are child messages, not flat twt. Not of course!

@prologic@twtxt.net interesting. What would happen on a hash collision? 🤔

@bender@twtxt.net It’s a bug in the UI for sure. The hash is the primary key.

(#yyriova) @bender@bender It’s a bug in the UI for sure. The hash is the primary key.
@bender @twtxt.net It’s a bug in the UI for sure. The hash is the primary key. ⌘ Read more

@david@collantes.us Yeah, we’ve been debugging that a bit yesterday. Looks like the wrong input (sometimes) gets fed to the hash function → broken threads.

@movq@www.uninformativ.de @kat@yarn.girlonthemoon.xyz Heck yeah, that’s crazy! :-) Fingers crossed! (tt also agrees with the right™ hash)

The actual hash is fs7673q.

@prologic@twtxt.net that’s not what I see. The hash znf6csa cannot be found.

@prologic@twtxt.net There was no edit according to my Git history. 🤔 On my end, the hash is fs7673q and that’s also what kat used to reply.

Doesn’t look like it Hmmm

sqlite> select * from twts where content LIKE '%Linux installation%';
    hash = znf6csa
feed_url = https://www.uninformativ.de/twtxt.txt
 content = I wonder if my current Linux installation will actually make it to 20 years:

    $ head -n 1 /var/log/pacman.log
    [2011-07-07 11:19] installed filesystem (2011.04-1)

It’s not toooo far into the future.

It would be crazy … 20 years without reinstalling once … phew. 🥴
 created = 2025-04-07T19:59:51Z
 subject = (#znf6csa)
mentions = []
    tags = []
   links = []

**(#2znenta) Doesn’t look like it Hmmm

sqlite> select * from twts where content LIKE '%Linux installation%';
    hash = znf6csa
feed_url = ht ...**
Doesn’t look like it Hmmm

sqlite> select * from twts where content LIKE ‘%Linux installation%’;

hash = znf6csa

feed_url = https://www.uninformativ.de/twtxt.txt
content = I wonder if my current Linux installation will actually make it to 20 years:

$ head -n 1 /var/log/pacman.log
[2011-07-07 11:19] installed filesystem (2011.04-1)

It’s not toooo far into the future.

It wou … ⌘ Read more

@movq@www.uninformativ.de Apparently you wrote it :D The hash doesn’t lie? 🤣 https://twtxt.net/twt/znf6csa

(#2znenta) @movq@movq Apparently you wrote it :D The hash doesn’t lie? 🤣
@movq @www.uninformativ.de Apparently you wrote it :D The hash doesn’t lie? 🤣 https://twtxt.net/twt/znf6csa ⌘ Read more

@prologic@twtxt.net What happened here – did I edit my twt or is this hash wrong? 🥴

@prologic@twtxt.net Spring cleanup! That’s one way to encourage people to self-host their feeds. :-D

Since I’m only interested in the url metadata field for hashing, I do not keep any comments or metadata for that matter, just the messages themselves. The last time I fetched was probably some time yesterday evening (UTC+2). I cannot tell exactly, because the recorded last fetch timestamp has been overridden with today’s by now.

I dumped my new SQLite cache into: https://lyse.isobeef.org/tmp/backup.tar.gz This time maybe even correctly, if you’re lucky. I’m not entirely sure. It took me a few attempts (date and time were separated by space instead of T at first, I normalized offsets +00:00 to Z as yarnd does and converted newlines back to U+2028). At least now the simple cross check with the Twtxt Feed Validator does not yield any problems.

@andros@twtxt.andros.dev sha256 hash of twt in json. Look at converter script

Amazing! It is a good tool for reading feeds. What you used to calculate the hash?

Hello, i want to present my new revolution twtxt v3 format - twjson
That’s why you should use it:

1. It’s easy to to parse
   
2. It’s easy to read (in formatted mode :D)
   
3. It used actually \n for newlines, you don’t need unprintable symbols
   
4. Forget about hash collisions because using full hash
   Here is my twjson feed: https://doesnm.p.psf.lt/twjson.json
   And twtxt2json converter: https://doesnm.p.psf.lt/twjson.js

@eapl.me@eapl.me Interesting! Two points stood right out to me:

1. Why the hell are e-mail newsletters considered a valid option in the first place? Just offer an Atom feed and be done with it! Especially for a blog of this very type. This doesn’t even involve a third party service. Although, in addition he also links to Feedburner, what the fuck!? No e-mail address or the like is needed and subject to being disclosed.

2. When these spam mailers want to prevent resubscribing, then for fuck’s sake, why don’t they use a hash of the e-mail address (I saw that in yarnd) for that purpose? Storing the e-mail address in clear text after unsubscribing is illegal in my book.

There are 82.108 read statuses, but only 24.421 messages in the cache. In contrast to the cache with the messages, the read statuses are never cleaned up when a feed was unsubscribed from. And the read statuses also contain old style hashes, before we settled on the what we have today. Still a huge difference. Hmm.

Thanks, @movq@www.uninformativ.de!

My backing SQLite database with indices is 8.7 MiB in size right now.

The twtxt cache is 7.6 MiB, it uses Python’s pickle module. And next to it there is a 16.0 MiB second database with all the read statuses for the old tt. Wow, super inefficient, it shouldn’t contain anything else, it’s a giant, pickled {"$hash": {"read": True/False}, …}. What the heck, why is it so big?! O_o

(Back in tt.) Well, it kinda worked. At least appending to the file. But my cache database got screwed up. I do not yet support replies, so the subject and and root hash columns have not been set at all, resulting in a message that is just not shown at all. I gotta do something about that next. The good thing is, though, after simply fixing the two columns the message appeared on screen.

@bender@twtxt.net Yeah, as you mentioned in the other thread, @andros@twtxt.andros.dev’s hashes appear to be not quite right. 🤔

@movq@www.uninformativ.de I have no doubt that you’re not seeing the images correctly 😀. It’s just that it’s broken when viewing them, in my case, and analyzing the URLs, I’ve seen everything I mentioned.
Regarding the hash, you’re right. I’ll have to investigate what’s going on. I’m having a hard time getting the hash generation to work properly.

@andros@twtxt.andros.dev Hm, looks correct to me. The image to be displayed is a thumbnail and this links to the full-sized image. The thumbnail (JPG) is auto-generated from the full image (PNG), hence the two extensions.

What does look strange, though, is that your client came up with the hash pqsmcka, while it should have been te5quba. 🤔

ditatompel releases ‘xmr-remote-nodes’ v0.2.1
ditatompel1 has released xmr-remote-nodes 2 version 0.2.13 with a fix for CVE-2024-453384, new features and updates:

”`

• fix: CVE-2024-45338 in #173
  
• feat: Added tor hidden service via HTTP header
  
• feat: Added more information on monero node details page
  
• feat: Added curl example command to Node details modal and page
  
• feat: Store hashed user IP address when submitting new node
  
• build(de … ⌘ Read more”`

(#j3xacqa) @eapl.me@eapl.me@eapl.me@eapl.me I think the general idea that we’re settling on here is that maybe we can build a simple solution …
@eapl.me @eapl.me @eapl.me @eapl.me I think the general idea that we’re settling on here is that maybe we can build a simple solution to this whole “wtf is this hash?” problem. yarnd already forms a sort-of “distributed network” amongst its pe … ⌘ Read more

Mathieu Pasquet: slixmpp v1.9.1
This is mostly a bugfix release over version 1.9.0.

The main fix is the rust JID implementation that would behave incorrectly when
hashed if the JID contained non-ascii characters. This is an important issue as
using a non-ascii JID was mostly broken, and interacting with one failed in
interesting ways.

• The previously mentioned JID hash issue
  
• Various edge cases in the roster code
  
• One edge case in the MUC ( [XEP-0045](https: … ⌘ Read more

Why not just use registry? It can be personal or hosted by someone like registry.twtxt.org. Just need to be adapt to support hashes

(#6gfpeea) @lyse@lyse Sorry I didn’t mean to upset you or anyone here in the community. I am/was merely trying to solve what I perce …
@lyse @lyse.isobeef.org Sorry I didn’t mean to upset you or anyone here in the community. I am/was merely trying to solve what I perceive to be a problem and an ask in the community:

How do I know what a hash refers to?

I believe the reason for this stems from a curiosity of the user of whether they might … ⌘ Read more

@prologic@twtxt.net We can’t agree on this idea because that makes things even more complicated than it already is today. The beauty of twtxt is, you put one file on your server, done. One. Not five million. Granted, there might be archive feeds, so it might be already a bit more, but still faaaaaaar less than one file per message.

Also, you would need to host not your own hash files, but everybody else’s as well you follow. Otherwise, what is that supposed to achieve? If people are already following my feed, they know what hashes I have, so this is to no use of them (unless they want to look up a message from an archive feed and don’t process them). But the far more common scenario is that an unknown hash originates from a feed that they have not subscribed to.

Additionally, yarnd’s URL schema would then also break, because https://twtxt.net/twt/<hash> now becomes https://twtxt.net/user/prologic/<hash>, https://twtxt.net/user/bender/<hash> and so on. To me, that looks like you would only get hashes if they belonged to this particular user. Of course, you could define rules that if there is a /user/ part in the path, then use a different URL, but this complicates things even more.

Sorry, I don’t like that idea.

One of the biggest gripes of the community with the way the threading model currently works with Twtxt v1.2 (https://twtxt.dev) is this notion of:

What is this hash?
What does it refer to?

Idea: Why can’t we all agree to implement a simple URI scheme where we host our Twtxt feeds?

That is, if you host your feed at https://example.com/twtxt.txt – Why can’t or could you not also host various JSON files (let’s agree on the spec of course) at https://example.com/twt/<hash> ? 🤔

That way we solve this problem in a truly decentralised way, rather than every relying on yarnd pods alone.

**One of the biggest gripes of the community with the way the threading model currently works with Twtxt v1.2 () is this notion of:

What is t …**
One of the biggest gripes of the community with the way the threading model currently works with Twtxt v1.2 ( https://twtxt.dev) is this notion of:

What is this hash?

What does it refer to?

Idea: Why can’t we all agree to implement a simple URI scheme where we host our Twtxt feeds?

That is, if you host your feed at https://example.com/twtxt.txt – Why can’t o … ⌘ Read more

Go-redis：執行 Lua 腳本
go-redis (github.com/redis/go-redis) 支持 Lua 腳本 redis.Script，本文在這裏簡單展示其在秒殺場景中使用的代碼片段。秒殺場景在秒殺場景中，一個商品的庫存對應了兩個信息，分別是總庫存量和已秒殺量。可以使用一個 Hash 類型的鍵值對來保存庫存的這兩個信息，如下所示：key: productid value: {total: N, ordered: ⌘ Read more

a few async ideas for later

The editing process needs a lot of consideration and compromises.

From one side, editing and deleting it’s necessary IMO. People will do it anyway, and personally I like to edit my texts, so I’d put some effort on make it work.
Should we keep a history of edits? Should we hash every edit to avoid abuse? Should we mark internally a twt as deleted, but keeping the replies?

I think that’s part of a more complete ‘thread’ extension, although I’d say it’s worth to agree on something reflecting the real usage in the wild, along with what people usually do on other platforms.

(#jwfdkuq) This seems to be capable of supporting edits as you noted. But I need to think a bit more (~2am here now) of whether this can be abus …
This seems to be capable of supporting edits as you noted. But I need to think a bit more (~2am here now) of whether this can be abused in any way… The advantage of Content-based Addressing ( hashing the content) is that the hash is then immutable, meaning that we can have integrity that the hash actually represents that content from that author at that time. ⌘ Read more

looks good to me!

About alice’s hash, using SHA256, I get 96473b4f or 96473B4F for the last 8 characters. I’ll add it as an implementation example.
The idea of including it besides the follow URL is to avoid calculating it every time we load the file (assuming the client did that correctly), and helps to track replies across the file with a simple search.

Also, watching your example I’m thinking now that instead of {url=96473B4F,id=1} which is ambiguous of which URL we are referring to, it could be something like:
{reply_to=[URL_HASH]_[TWT_ID]} / {reply_to=96473B4F_1}
That way, the ‘full twt ID’ could be 96473B4F_1.

True. Though if the idea turns out to be better.. then community will adopt it.

if you look at the subject for that twt you will see that it uses the extended hash format to include a URL address.

True. Though if the idea turns out to be better.. then community will adopt it.

if you look at the subject for that twt you will see that it uses the extended hash format to include a URL address.

@bmallred@staystrong.run I forgot one more effect of edits. If clients remember the read status of massages by hash, an edit will mark the updated message as unread again. To some degree that is even the right behavior, because the message was updated, so the user might want to have a look at the updated version. On the other hand, if it’s just a small typo fix, it’s maybe not worth to tell the user about. But the client doesn’t know, at least not with additional logic.

Having said that, it appears that this only affects me personally, noone else. I don’t know of any other client that saves read statuses. But don’t worry about me, all good. Just keep doing what you’ve done so far. I wanted to mention that only for the sake of completeness. :-)

I like this syntax, you have my vote, although I’d change it a bit like
#<Alice https://example.com/twtxt.com#2024-12-18T14:18:26+01:00>

Hashes are not a problem on PHP, I dont know why it’s slow to calculate them from your side, but I agree with your points.

BTW, did you have the chance to read my proposal on twtxt 2.0? I shared a few ideas about possible improvements to discuss:
https://text.eapl.mx/a-few-ideas-for-a-next-twtxt-version
https://text.eapl.mx/reply-to-lyse-about-twtxt

@bmallred@staystrong.run Any edit automatically changes the twt hash, because the hash is built over the hash URL, message timestamp and message text. https://twtxt.dev/exts/twt-hash.html So, it is only a problem, if somebody replied to your original message with the old hash. The original message suddenly doesn’t exist anymore and the reply becomes detached, orphaned, whatever you wanna call it. Threading doesn’t break, though, if nobody replied to your message.

@andros@twtxt.andros.dev I believe you have just reproduced the bug… it looks like you’ve replayed to a twt but the hash is wrong. I can see the hash here from Jenny, but it doesn’t look like it corresponds to any{twt,thing}. if you check it out on any yarn instance it won’t look like a replay.

My hypothesis about that thing breaking my twts is that it might have something to do with the parenthesis surrounding the root twt hash in the replay twt-A when I replay to it with fork-twt-B; I imagine elisp interpreting those as a s-expression thus breaking the generation precess of hash (#twt-A) before prepending it to for-twt-B … but then I’m too ignorant to figure out how to test my theory (heck I couldn’t even recalculate the hashes myself correctly in bash xD). I’ll keep trying tho.

@andros@twtxt.andros.dev yes, that usually happens when twts get edited and we just made a gentlemen agreement to avoid edits as much as possible (at least for the time being). But the thing is, That is not what’s happening with my broken twts’ hashes. Since I’ve bee mostly replaying to my own twts as a test and I know for sure that I haven’t edited any. (I usually fork-replay instead of edit a twt when needed)

@aelaraji@aelaraji.com Can you give me examples of hashes that you have detected wrong between Emacs client and twtxt.net?
Perhaps there is some character, some space, that is creating the discrepancy.

@prologic@twtxt.net Agreed! But clients can hallucinate and generate wrong hashes aka Lies 🤣 Also, If you chheck your own twt on twtxt.net, it looks like a root twt instead of a replay.

@aelaraji@aelaraji.com hashes don’t lie 🤣

(#dpkemhq) @aelaraji@aelaraji hashes don’t lie 🤣
@aelaraji @aelaraji.com hashes don’t lie 🤣 ⌘ Read more

the hash in that test replay should have been s243lua instead 🤷

@prologic@twtxt.net Are you sure? xD … it was supposed to be a replay to another twt, but the twt hash is wrong (I think).

@andros@twtxt.andros.dev is it me or twtxt-el generates a wrong twt hash when I use the [ ↳ Reply to twt ] button?

分佈式基石算法 一致性 hash
什麼是 一致性 hash 算法—————首先摘抄一段維基百科的定義  一致哈希 是一種特殊的哈希算法。在使用一致哈希算法後，哈希表槽位數（大小）的改變平均只需要對𝐾/𝑛 個關鍵字重新映射，其中 𝐾 是關鍵字的數量，𝑛是槽位數量。然而在傳統的哈希表中，添加或刪除一個槽位的幾乎需要對所有關鍵字進行重新映射。 — wikipedia分佈式系統中, 一致性 hash 無處不在，C ⌘ Read more

@prologic@twtxt.net Of course you don’t notice it when yarnd only shows at most the last n messages of a feed. As an example, check out mckinley’s message from 2023-01-09T22:42:37Z. It has “[Scheduled][Scheduled][Scheduled]“… in it. This text in square brackets is repeated numerous times. If you search his feed for closing square bracket followed by an opening square bracket (][) you will find a bunch more of these. It goes without question he never typed that in his feed. My client saves each twt hash I’ve explicitly marked read. A few days ago, I got plenty of apparently years old, yet suddenly unread messages. Each and every single one of them containing this repeated bracketed text thing. The only conclusion is that something messed up the feed again.

(#py6tmvq) @mckinley@mckinley I’m worried we’re really approaching a point where we need to adapt the hashing algorithm and expand the no. of …
@mckinley @twtxt.net I’m worried we’re really approaching a point where we need to adapt the hashing algorithm and expand the no. of bits. Is it at all possible something else is going on here though? 🤞 ⌘ Read more

Definitely something going on with replies. This one was replying to the wrong twt and even when I got clever and pasted the right hash it didn’t work.

I’m realizing that my performance bottleneck is @prologic@twtxt.net ! It is actually calculating the hash to make the replicas, and specifically users with very long feeds 😂 . I’m seriously thinking about enabling replies via configuration.

Well, that’s another bug: The search https://twtxt.net/search?q=%22LOOOOL%2C+great+programming+tutorial+music%22 yields the wrong hash. It should have been poyndha instead.

@lyse@lyse.isobeef.org Danke! Ja, es gibt noch unzählige Stellschrauben an dem Ding. Deine Anmerkungen werde ich einarbeiten. Eine mobile Ansicht wär auch noch schön. Derzeit sitzt es auf dem Smartphone doch noch recht stramm.

@Unterhaltungen: Die von gestern zu verschlüsselten Nachrichten war ausschlaggebend für die Umsetzung. In “Timeline” und “Yarn” haben mich die Lösungsansätze bisher nicht überzeugt. Aber wir können ja alle etwas von einander lernen.

another one would be to allow changing public keys over time (as it may be a good practice [0]). A syntax like the following could help to know what public key you used to encrypt the message, and which private key the client should use to decrypt it:

!<nick url> <encrypted_message> <public_key_hash_7_chars>

Also I’d remove support for storing the message as hex, only allowing base64 (more compact, aiming for a minimalistic spec, etc.)

[0] https://www.brandonchecketts.com/archives/its-2023-you-should-be-using-an-ed25519-ssh-key-and-other-current-best-practices

Or using the same twt hash method, but only for the URL, to generate the nick, if it doesn’t exist, like so, @5vxo4ia@twtxt.net

@doesnmppsflt@doesnm.p.psf.lt Not sure which bug you’re referring to. 🤔 (Did I forget?)

Those long IDs like (#113797927355322708) are simply part of that feed. Looks like the author just dumps ActivityPub IDs into twtxt. I think this used to work in the past, but the corresponding spec (https://twtxt.dev/exts/hash-tag.html) has been deprecated and jenny doesn’t support – actually, jenny never supported that.

jenny can only group threads by exactly one criterium (because it writes a Message-ID into the mail file) and that’s the regular twt hash. So, anything else, like people doing “#CoolTopic”, isn’t possible.

I’m still making progress with the Emacs client. I’m proud to say that the code that is responsible for reading the feeds is almost finished, including: Twt Hash Extension, Twt Subject Extension, Multiline Extension and Metadata Extension. I’m fine-tuning some tests and will soon do the first buffer that displays the twts.

(#rejodqa) That’s why we use hashes 😅
That’s why we use hashes 😅 ⌘ Read more

Added TwtHash hashes to every message on my personal Twtxt HTML renderer. Code is not yet ready for prime-time. Need to work out some kinks still.

rehrar releases Stack Wallet v2.1.9, Stack Duo v1.2.4
rehrar1 has released Stack Wallet2 version 2.1.93 and Stack Duo version 1.2.44 with various fixes and improvements.

Stack Wallet:
* Show Monero/Wownero tx private key option
* Fix Frost error
* Stack Wallet Backup fixes
Stack Duo:
* Added Monero churn options
* Paynym temporarily disabled while kinks worked out [..]

The release notes, binaries, and the SHA256 hashes can … ⌘ Read more

**(#dy3n2cq) Also interesting:

edit_hash: When a message is edited, a new message is created– this field holds the hash of the modified messag …**
Also interesting:

edit_hash: When a message is edited, a new message is created– this field holds the hash of the modified message. The client follows the chain of edit hashes to end up at the final, edited message to display. This lets us keep an “undo” history (not yet implemented) and is a marker so the client can display a marker that the message has been edited. ⌘ Read more

**(#dy3n2cq) @bender@bender Thanks! Also very interesting rid bits here 🤣

The author, parent hash, timestamp, and message values go into …**
@bender Thanks! Also very interesting rid bits here 🤣

The author, parent hash, timestamp, and message values go into the hash. (see Message Hash for details) ⌘ Read more

**(#dy3n2cq) LOL the rest of it appears undocumented 🤦‍♂️

Messages

Message Hash

Bad Hashes

Edit Chain

Deleted Messages

Topic List

…**
LOL the rest of it appears undocumented 🤦‍♂️

Messages

Message Hash

Bad Hashes

Edit Chain

Deleted Messages

Topic List

Replies

License

GPLv2 ⌘ Read more

**(#dy3n2cq) @skinshafi Cool!

Iris leans heavily on convention. Iris’ security and message authentication is provided by filesystem permissions …**
@skinshafi @thunix.net Cool!

Iris leans heavily on convention. Iris’ security and message authentication is provided by filesystem permissions and message hashing. ⌘ Read more

一文搞懂如何在 Go 包中支持 Hash-Based Bisect 調試
bisect 是一個英文動詞，意爲 “二分” 或“分成兩部分”。在數學和計算機科學中，通常指將一個區間或一個集合分成兩個相等的部分。對於程序員來說，最熟悉的 bisect 應用莫過於下面兩個：算法中的二分查找 (binary search) 二分查找是一個經典且高效的查找算法，任何一本介紹數據結構或計算機算法的書都會包含對二分查找的系統說明。所謂二分查找就是通過不斷將搜索區間一分爲二來找到目 ⌘ Read more

Go 中祕而不宣的數據結構 maphash：性能之王
哈希算法 (也稱散列算法) 是一種將任意長度的輸入數據轉換成固定長度輸出的數學算法。Hash 算法的應用場景Hash 算法常常用在以下的場景中：數據完整性驗證 可以爲文件生成唯一的哈希值，用於檢測文件是否被篡改 常見場景如軟件下載時的 MD5 校驗、區塊鏈中的數據驗證 密碼存儲安全 不直接存儲用戶密碼原文, 而是存儲密碼的哈希值 即使數據庫被攻破, 黑客也無法直接獲取 ⌘ Read more

@bender@twtxt.net So turns out something is setting my HashingURI to the value {{ .Profile.URI }} and that is making my hashes wrong so it cannot delete or edit twts.

@bender@twtxt.net So turns out something is setting my HashingURI to the value {{ .Profile.URI }} and that is making my hashes wrong so it cannot delete or edit twts.

Righto, @eapl.me@eapl.me, ta for the writeup. Here we go. :-)

Metadata on individual twts are too much for me. I do like the simplicity of the current spec. But I understand where you’re coming from.

Numbering twts in a feed is basically the attempt of generating message IDs. It’s an interesting idea, but I reckon it is not even needed. I’d simply use location based addressing (feed URL + ‘#’ + timestamp) instead of content addressing. If one really wanted to, one could hash the feed URL and timestamp, but the raw form would actually improve disoverability and would not even require a richer client. But the majority of twtxt users in the last poll wanted to stick with content addressing.

yarnd actually sends If-Modified-Since request headers. Not only can I observe heaps of 304 responses for yarnds in my access log, but in Cache.FetchFeeds(…) we can actually see If-Modified-Since being deployed when the feed has been retrieved with a Last-Modified response header before: https://git.mills.io/yarnsocial/yarn/src/commit/98eee5124ae425deb825fb5f8788a0773ec5bdd0/internal/cache.go#L1278

Turns out etags with If-None-Match are only supported when yarnd serves avatars (https://git.mills.io/yarnsocial/yarn/src/commit/98eee5124ae425deb825fb5f8788a0773ec5bdd0/internal/handlers.go#L158) and media uploads (https://git.mills.io/yarnsocial/yarn/src/commit/98eee5124ae425deb825fb5f8788a0773ec5bdd0/internal/media_handlers.go#L71). However, it ignores possible etags when fetching feeds.

I don’t understand how the discovery URLs should work to replace the User-Agent header in HTTP(S) requests. Do you mind to elaborate?

Different protocols are basically just a client thing.

I reckon it’s best to just avoid mixing several languages in one feed in the first place. Personally, I find it okay to occasionally write messages in other languages, but if that happens on a more regularly basis, I’d definitely create a different feed for other languages.

Isn’t the emoji thing “just” a client feature? So, feed do not even have to state any emojis. As a user I’d configure my client to use a certain symbol for feed ABC. Currently, I can do a similar thing in tt where I assign colors to feeds. On the other hand, what if a user wants to control what symbol should be displayed, similar to the feed’s nick? Hmm. But still, my terminal font doesn’t even render most of emojis. So, Unicode boxes everywhere. This makes me think it should actually be a only client feature.

(#nvrq7lq) @eapl.me There’s some good ideas in this 👌 I think we can definitely incorporate some of them pretty easily already. Others will …
@eapl.me @eapl.me There’s some good ideas in this 👌 I think we can definitely incorporate some of them pretty easily already. Others will have to be discussed, and some other bits like hashing and edits are a bit more controversial. ⌘ Read more

Monerujo adds support for Exolix exchange in v4.1.2
m2049r1 has released Monerujo2 version 4.1.23 with support for crypto exchange platform Exolix 4:

Upgrading to Monero Core to v0.18.3.4
Add support for Exolix exchange
Minor bugfixes
Some refactoring

Before usage it is recommended to back up your seed and verify that you have downloaded the correct file using the SHA256 hash listed on Github3.

If you need help, consult the … ⌘ Read more

(#pqhbula) @Codebuzz I really like this idea of just using the Feed’s # nick as a sort of “identifier”. This gets us out of this mess of when …
@Codebuzz @www.codebuzz.nl I really like this idea of just using the Feed’s # nick as a sort of “identifier”. This gets us out of this mess of when feeds move locations or authors decide to host on 3 or 4 different protocols 🤣 Downside? Something picks the same nick? ( _they’ll still hash differently, so th … ⌘ Read more

(#rjapt4a) @movq@movq Don’t we use the last url for hashing? 🤔
@movq @www.uninformativ.de Don’t we use the last url for hashing? 🤔 ⌘ Read more

(#rjapt4a) @movq I’m assuming jenny is doing some kind of validation and verifying if that Twt really does exist on the feed uri? 🤔 But the …
@movq @www.uninformativ.de I’m assuming jenny is doing some kind of validation and verifying if that Twt really does exist on the feed uri? 🤔 But the hash is all kinds of wrong now because @gallowsgryph for whatever reason decided it might be a good idea to have a 2nd # url that doesn’t actually point to t … ⌘ Read more

@movq@www.uninformativ.de i’m sorry if I sound too contrarian. I’m not a fan of using an obscure hash as well. The problem is that of future and backward compatibility. If we change to sha256 or another we don’t just need to support sha256. But need to now support both sha256 AND blake2b. Or we devide the community. Users of some clients will still use the old algorithm and get left behind.

Really we should all think hard about how changes will break things and if those breakages are acceptable.

@movq@www.uninformativ.de i’m sorry if I sound too contrarian. I’m not a fan of using an obscure hash as well. The problem is that of future and backward compatibility. If we change to sha256 or another we don’t just need to support sha256. But need to now support both sha256 AND blake2b. Or we devide the community. Users of some clients will still use the old algorithm and get left behind.

Really we should all think hard about how changes will break things and if those breakages are acceptable.

I share I did write up an algorithm for it at some point I think it is lost in a git comment someplace. I’ll put together a pseudo/go code this week.

Super simple:

Making a reply:

1. If yarn has one use that. (Maybe do collision check?)
   
2. Make hash of twt raw no truncation.
   
3. Check local cache for shortest without collision
   
   • in SQL: select len(subject) where head_full_hash like subject || '%'
     

Threading:

1. Get full hash of head twt
   
2. Search for twts
   
   • in SQL: head_full_hash like subject || '%' and created_on > head_timestamp
     

The assumption being replies will be for the most recent head. If replying to an older one it will use a longer hash.

I share I did write up an algorithm for it at some point I think it is lost in a git comment someplace. I’ll put together a pseudo/go code this week.

Super simple:

Making a reply:

1. If yarn has one use that. (Maybe do collision check?)
   
2. Make hash of twt raw no truncation.
   
3. Check local cache for shortest without collision
   
   • in SQL: select len(subject) where head_full_hash like subject || '%'
     

Threading:

1. Get full hash of head twt
   
2. Search for twts
   
   • in SQL: head_full_hash like subject || '%' and created_on > head_timestamp
     

The assumption being replies will be for the most recent head. If replying to an older one it will use a longer hash.

If we stuck with Blake2b for Twt Hash(es); what do we think we need to reasonably go to in bit length/size?

=> https://gist.mills.io/prologic/194993e7db04498fa0e8d00a528f7be6

e.g: (turns out @xuu@txt.sour.is is right about Blak2b being easy/simple too!):

$ printf "%s\t%s\t%s" "https://example.com/twtxt.txt" "2024-09-29T13:30:00Z" "Hello World!" | b2sum -l 32 -t | awk '{ print $1 }'
7b8b79dd

These collisions aren’t important unless someone tries to fork. So.. for the vast majority its not a big deal. Using the grow hash algorithm could inform the client to add another char when they fork.

These collisions aren’t important unless someone tries to fork. So.. for the vast majority its not a big deal. Using the grow hash algorithm could inform the client to add another char when they fork.

Thanks @david@collantes.us, good to know, but we need to agree on what character we use, otherwise the hashes will not be the same:)

Ok, i know how to command working (not sure), but seems it only grab from cache. Maybe make fetch from twtxt.net if hash not found?

@prologic@twtxt.net Regarding the new way of generating twt-hashes, to me it makes more sense to use tabs as separator instead of spaces, since the you can just copy/past a line directly from a twtxt-file that already go a tab between timestamp and message. But tabs might be hard to “type” when you are in a terminal, since it will activate autocomplete…🤔

Another thing, it seems that you sugget we only use the domain in the hash-creation and not the full path to the twtxt.txt

$ echo -e "https://example.com 2024-09-29T13:30:00Z Hello World!" | sha256sum - | awk '{ print $1 }' | base64 | head -c 12

@doesnm@doesnm.p.psf.lt twt probably isn’t the best client I’m afraid. It doesn’t really cache twts by their key (hash) to display threads properly. Jenny however does 👌