@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

**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

(#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

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.

@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)

@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.

(#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

(#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

(#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.

(#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.

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.

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

twet display twts in raw format with some formatting (sadly no newlines). And for reply messages i just seen (#hash). But which text hidden on hash? currenly im open twtxt.net/twt/hash to see this

More thoughts about changes to twtxt (as if we haven’t had enough thoughts):

1. There are lots of great ideas here! Is there a benefit to putting them all into one document? Seems to me this could more easily be a bunch of separate efforts that can progress at their own pace:
   

1a. Better and longer hashes.

1b. New possibly-controversial ideas like edit: and delete: and location-based references as an alternative to hashes.

1c. Best practices, e.g. Content-Type: text/plain; charset=utf-8

1d. Stuff already described at dev.twtxt.net that doesn’t need any changes.

1. We won’t know what will and won’t work until we try them. So I’m inclined to think of this as a bunch of draft ideas. Maybe later when we’ve seen it play out it could make sense to define a group of recommended twtxt extensions and give them a name.

2. Another reason for 1 (above) is: I like the current situation where all you need to get started is these two short and simple documents:
   https://twtxt.readthedocs.io/en/latest/user/twtxtfile.html
   https://twtxt.readthedocs.io/en/latest/user/discoverability.html
   and everything else is an extension for anyone interested. (Deprecating non-UTC times seems reasonable to me, though.) Having a big long “twtxt v2” document seems less inviting to people looking for something simple. (@prologic@twtxt.net you mentioned an anonymous comment “you’ve ruined twtxt” and while I don’t completely agree with that commenter’s sentiment, I would feel like twtxt had lost something if it moved away from having a super-simple core.)

3. All that being said, these are just my opinions, and I’m not doing the work of writing software or drafting proposals. Maybe I will at some point, but until then, if you’re actually implementing things, you’re in charge of what you decide to make, and I’m grateful for the work.

@prologic@twtxt.net Done. Also, I went ahead and made two changes: changed hexadecimal to base64 for hashes (wasn’t sure if anyone objected), and changed “MUST follow the chain” to “SHOULD follow the chain.

(#2024-09-24T12:44:35Z) There is a increase in space/memory for sure. But calculating the hashes also takes up CPU. I’m not good with that kind of math, but it’s a tradeoff either way.

@falsifian@www.falsifian.org I believe the preserve means to include the original subject hash in the start of the twt such as (#somehash)

@bender@twtxt.net

Sorry, you’re right, I should have used numbers!

I’m don’t understand what “preserve the original hash” could mean other than “make sure there’s still a twt in the feed with that hash”. Maybe the text could be clarified somehow.

I’m also not sure what you mean by markdown already being part of it. Of course people can already use Markdown, just like presumably nothing stopped people from using (twt subjects) before they were formally described. But it’s not universal; e.g. as a jenny user I just see the plain text.

@prologic@twtxt.net Thanks for writing that up!

I hope it can remain a living document (or sequence of draft revisions) for a good long time while we figure out how this stuff works in practice.

I am not sure how I feel about all this being done at once, vs. letting conventions arise.

For example, even today I could reply to twt abc1234 with “(#abc1234) Edit: …” and I think all you humans would understand it as an edit to (#abc1234). Maybe eventually it would become a common enough convention that clients would start to support it explicitly.

Similarly we could just start using 11-digit hashes. We should iron out whether it’s sha256 or whatever but there’s no need get all the other stuff right at the same time.

I have similar thoughts about how some users could try out location-based replies in a backward-compatible way (append the replyto: stuff after the legacy (#hash) style).

However I recognize that I’m not the one implementing this stuff, and it’s less work to just have everything determined up front.

Misc comments (I haven’t read the whole thing):

• Did you mean to make hashes hexadecimal? You lose 11 bits that way compared to base32. I’d suggest gaining 11 bits with base64 instead.

• “Clients MUST preserve the original hash” — do you mean they MUST preserve the original twt?

• Thanks for phrasing the bit about deletions so neutrally.

• I don’t like the MUST in “Clients MUST follow the chain of reply-to references…”. If someone writes a client as a 40-line shell script that requires the user to piece together the threading themselves, IMO we shouldn’t declare the client non-conforming just because they didn’t get to all the bells and whistles.

• Similarly I don’t like the MUST for user agents. For one thing, you might want to fetch a feed without revealing your identty. Also, it raises the bar for a minimal implementation (I’m again thinking again of the 40-line shell script).

• For “who follows” lists: why must the long, random tokens be only valid for a limited time? Do you have a scenario in mind where they could leak?

• Why can’t feeds be served over HTTP/1.0? Again, thinking about simple software. I recently tried implementing HTTP/1.1 and it wasn’t too bad, but 1.0 would have been slightly simpler.

• Why get into the nitty-gritty about caching headers? This seems like generic advice for HTTP servers and clients.

• I’m a little sad about other protocols being not recommended.

• I don’t know how I feel about including markdown. I don’t mind too much that yarn users emit twts full of markdown, but I’m more of a plain text kind of person. Also it adds to the length. I wonder if putting a separate document would make more sense; that would also help with the length.

I wrote some code to try out non-hash reply subjects formatted as (replyto ), while keeping the ability to use the existing hash style.

I don’t think we need to decide all at once. If clients add support for a new method then people can use it if they like. The downside of course is that this costs developer time, so I decided to invest a few hours of my own time into a proof of concept.

With apologies to @movq@www.uninformativ.de for corrupting jenny’s beautiful code. I don’t write this expecting you to incorporate the patch, because it does complicate things and might not be a direction you want to go in. But if you like any part of this approach feel free to use bits of it; I release the patch under jenny’s current LICENCE.

Supporting both kinds of reply in jenny was complicated because each email can only have one Message-Id, and because it’s possible the target twt will not be seen until after the twt referencing it. The following patch uses an sqlite database to keep track of known (url, timestamp) pairs, as well as a separate table of (url, timestamp) pairs that haven’t been seen yet but are wanted. When one of those “wanted” twts is finally seen, the mail file gets rewritten to include the appropriate In-Reply-To header.

Patch based on jenny commit 73a5ea81.

https://www.falsifian.org/a/oDtr/patch0.txt

Not implemented:

• Composing twts using the (replyto …) format.
  
• Probably other important things I’m forgetting.

@quark@ferengi.one It does not. That is why I’m advocating for not using hashes for treads, but a simpler link-back scheme.