Oh boy, I’m looking for trapezoidal (like ACME thread) screws and nuts in left hand form. The rods are already expensive, but nuts feel like a total ripoff. A hex nut for Tr20x2 being 30mm long and 30mm in “diameter” costs me 22 bucks! O_o Just a single one, made of regular steel. A meter of rod is 21€. The more common Tr20x4 hex nut is just 7€ and the rod 17€, but 4mm pitch is a bit much for a leadscrew for semi-precision work I reckon.

Well, maybe I just use metric threads. I will sleep on this.

I mean thread command but bash escapes quoted as command…

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

@prologic@twtxt.net YES James, it should be up to the client to deal with changes like edits and deletions. And putting this load on the clients, location-addressing with make this a lot easier since what is says it: Look in this file at this timestamp, did anything change or went missing? (And then threading will not break;)

@bender@twtxt.net I am also in camp no edit signals. deletes only breaks the head of a thread. all the replies are unaffected.

@bender@twtxt.net Re that broken thread (#bqor23a). Its the same one. My pod doesn’t have the Root Twt: https://twtxt.net/twt/bqor23a => 404 Not Found.

How in the hell did you even reply to this in the first place?

@sorenpeter@darch.dk Points 2 & 3 aren’t really applicable here in the discussion of the threading model really I’m afraid. WebMentions is completely orthogonal to the discussion. Further, no-one that uses Twtxt really uses WebMentions, whilst yarnd supports the use of WebMentions, it’s very rarely used in practise (if ever) – In fact I should just drop the feature entirely.

The use of WebSub OTOH is far more useful and is used by every single yarnd pod everywhere (no that there’s that many around these days) to subscribe to feed updates in ~near real-time without having the poll constantly.

#fzf is the new emacs: a tool with a simple purpose that has evolved to include an #email client. https://sr.ht/~rakoo/omail/

I’m being a little silly, of course. fzf doesn’t actually check your email, but it appears to be basically the whole user interface for that mail program, with #mblaze wrangling the emails.

I’ve been thinking about how I handle my email, and am tempted to make something similar. (When I originally saw this linked the author was presenting it as an example tweaked to their own needs, encouraging people to make their own.)

This approach could surely also be combined with #jenny, taking the place of (neo)mutt. For example mblaze’s mthread tool presents a threaded discussion with indentation.

@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’m still more in favor of (replyto:…). It’s easier to implement and the whole edits-breaking-threads thing resolves itself in a “natural” way without the need to add stuff to the protocol.

I’d love to try this out in practice to see how well it performs. 🤔 It’s all very theoretical at the moment.

@falsifian@www.falsifian.org comments on the feeds as in nick, url, follow, that kind of thing? If that, then not interested at all. I envision an archive that would allow searching, and potentially browsing threads on a nice, neat interface. You will have to think, though, on other things. Like, what to do with images? Yarn allows users to upload images, but also embed it in twtxts from other sources (hotlinking, actually).

@prologic@twtxt.net I know the role of the current hash is to allow referencing (replies and, thus, threads), and it also represents a “unique” way to verify a twtxt hasn’t been tampered with. Is that second so important, if we are trying to allow edits? I know if feels good to be able to verify, but in reality, how often one does it?

@prologic@twtxt.net how about hashing a combination of nick/timestamp, or url/timestamp only, and not the twtxt content? On edit those will not change, so no breaking of threads. I know, I know, just adding noise here. :-P

@prologic@twtxt.net the basic idea was to stem the hash.. so you have a hash abcdef0123456789... any sub string of that hash after the first 6 will match. so abcdef, abcdef012, abcdef0123456 all match the same. on the case of a collision i think we decided on matching the newest since we archive off older threads anyway. the third rule was about growing the minimum hash size after some threshold of collisions were detected.

@sorenpeter@darch.dk hmm, how does your client handles “a little editing”? I am sure threads would break just as well. 😉

@movq@www.uninformativ.de going a little sideways on this, “*If twtxt/Yarn was to grow bigger, then this would become a concern again. But even Mastodon allows editing, so how much of a problem can it really be? 😅*”, wouldn’t it preparing for a potential (even if very, very, veeeeery remote) growth be a good thing? Mastodon signs all messages, keeps a history of edits, and it doesn’t break threads. It isn’t a problem there.😉 It is here.

I think keeping hashes is a must. If anything for that “feels good” feeling.

Regarding jenny development: There have been enough changes in the last few weeks, imo. I want to let things settle for a while (potential bugfixes aside) and then I’m going to cut a new release.

And I guess the release after that is going to include all the threading/hashing stuff – if we can decide on one of the proposals. 😂

@quark@ferengi.one Oh, sure, it would be nice if edits didn’t break threads. I was just pondering the circumstances under which I get annoyed about data being irrecoverably deleted or otherwise lost.

@quark@ferengi.one I don’t really mind if the twt gets edited before I even fetch it. I think it’s the idea of my computer discarding old versions it’s fetched, especially if it’s shown them to me, that bugs me.

But I do like @movq@www.uninformativ.de’s suggestion on this thread that feeds could contain both the original and the edited twt. I guess it would be up to the author.

@prologic@twtxt.net sorry but nope. Neither jenny, nor yarnd supports it at all. This was treated as a thread because I picked one of @falsifian@www.falsifian.org’s twtxts (with the “old subject”), and replied to it (hence starting the thread).

@prologic@twtxt.net based on @falsifian@www.falsifian.org’s findings, I don’t believe this is quite accurate.

“yarnd(_at least_) doesn't support creating such a custom TwtSubject, but it will reply and respect and thread one if one was constructed."

Hmm, but yarnd also isn’t showing these twts as being part of a thread. @prologic@twtxt.net you said yarnd respects customs subjects. Shouldn’t these twts count as having a custom subject, and get threaded together?

@sorenpeter@darch.dk I like this idea. Just for fun, I’m using a variant in this twt. (Also because I’m curious how it non-hash subjects appear in jenny and yarn.)

URLs can contain commas so I suggest a different character to separate the url from the date. Is this twt I’ve used space (also after “replyto”, for symmetry).

I think this solves:

• Changing feed identities: although @mckinley@twtxt.net points out URLs can change, I think this syntax should be okay as long as the feed at that URL can be fetched, and as long as the current canonical URL for the feed lists this one as an alternate.
  
• editing, if you don’t care about message integrity
  
• finding the root of a thread, if you’re not following the author
  

An optional hash could be added if message integrity is desired. (E.g. if you don’t trust the feed author not to make a misleading edit.) Other recent suggestions about how to deal with edits and hashes might be applicable then.

People publishing multiple twts per second should include sub-second precision in their timestamps. As you suggested, the timestamp could just be copied verbatim.

Just that yarnd (at least) doesn’t support creating such a custom TwtSubject, but it will reply and respect and thread one if one was constructed.

This scheme also only support threading off a specific Twt of someone’s feed. What if you’re not replying to anyone in particular?

@sorenpeter@darch.dk

1. (replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z)
   

I think I like this a lot. 🤔

The problem with using hashes always was that they’re “one-directional”: You can construct a hash from URL + timestamp + twt, but you cannot do the inverse. When I see “, I have no idea what that could possibly refer to.

But of course something like (replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z) has all the information you need. This could simplify twt/feed discovery quite a bit, couldn’t it? 🤔 That thing that I just implemented – jenny asking some Yarn pod for some twt hash – would not be necessary anymore. Clients could easily and automatically fetch complete threads instead of requiring the user to follow all relevant feeds.

Only using the timestamp to identify a twt also solves the edit problem.

It even is better for non-Yarn clients, because you now don’t have to read, understand, and implement a “twt hash specification” before you can reply to someone.

The only problem, really, is that (replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z) is so long. Clients would have to try harder to hide this. 😅

@quark@ferengi.one No can do! I can’t see any of the replies to that thread, not even mine LOL. let me se if I can fetch @sorenpeter@darch.dk ’s feed with the https link.

Alright, I saw enough broken threads lately to be motivated enough to extend the --fetch-context thingy: It can now ask Yarn pods for twt hashes.

https://www.uninformativ.de/git/jenny/commit/eefd3fa09083e2206ed0d71887d2ef2884684a71.html

This is only done as a last resort if there’s no other way to find the missing twt. Like, when there’s a twt that begins with just a hash and no user mention, there’s no way for jenny to know on which feed that twt can be found, so it’ll ask some Yarn pod in that case.

@prologic@twtxt.net

They’re in Section 6:

• Receiver should adopt UDP GRO. (Something about saving CPU processing UDP packets; I’m a but fuzzy about it.) And they have suggestions for making GRO more useful for QUIC.

• Some other receiver-side suggestions: “sending delayed QUICK ACKs”; “using recvmsg to read multiple UDF packets in a single system call”.

• Use multiple threads when receiving large files.

So this is a great thread. I have been thinking about this too.. and what if we are coming at it from the wrong direction? Identity being tied to a given URL has always been a pain point. If i get a new URL its almost as if i have a new identity because not only am I serving at a new location but all my previous communications are broken because the hashes are all wrong.

What if instead we used this idea of signatures to thread the URLs together into one identity? We keep the URL to Hash in place. Changing that now is basically a no go. But we can create a signature chain that can link identities together. So if i move to a new URL i update the chain hosted by my primary identity to include the new URL. If i have an archived feed that the old URL is now dead, we can point to where it is now hosted and use the current convention of hashing based on the first url:

The signature chain can also be used to rotate to new keys over time. Just sign in a new key or revoke an old one. The prior signatures remain valid within the scope of time the signatures were made and the keys were active.

The signature file can be hosted anywhere as long as it can be fetched by a reasonable protocol. So say we could use a webfinger that directs to the signature file? you have an identity like frank@beans.co that will discover a feed at some URL and a signature chain at another URL. Maybe even include the most recent signing key?

From there the client can auto discover old feeds to link them together into one complete timeline. And the signatures can validate that its all correct.

I like the idea of maybe putting the chain in the feed preamble and keeping the single self contained file.. but wonder if that would cause lots of clutter? The signature chain would be something like a log with what is changing (new key, revoke, add url) and a signature of the change + the previous signature.

# chain: ADDKEY kex14zwrx68cfkg28kjdstvcw4pslazwtgyeueqlg6z7y3f85h29crjsgfmu0w 
# sig: BEGIN SALTPACK SIGNED MESSAGE. ... 
# chain: ADDURL https://txt.sour.is/user/xuu
# sig: BEGIN SALTPACK SIGNED MESSAGE. ...
# chain: REVKEY kex14zwrx68cfkg28kjdstvcw4pslazwtgyeueqlg6z7y3f85h29crjsgfmu0w
# sig: ...

@mckinley@twtxt.net To answer some of your questions:

Are SSH signatures standardized and are there robust software libraries that can handle them? We’ll need a library in at least Python and Go to provide verified feed support with the currently used clients.

We already have this. Ed25519 libraries exist for all major languages. Aside from using ssh-keygen -Y sign and ssh-keygen -Y verify, you can also use the salty CLI itself (https://git.mills.io/prologic/salty), and I’m sure there are other command-line tools that could be used too.

If we all implemented this, every twt hash would suddenly change and every conversation thread we’ve ever had would at least lose its opening post.

Yes. This would happen, so we’d have to make a decision around this, either a) a cut-off point or b) some way to progressively transition.

@lyse@lyse.isobeef.org This looks like a nice way to do it.

Another thought: if clients can’t agree on the url (for example, if we switch to this new way, but some old clients still do it the old way), that could be mitigated by computing many hashes for each twt: one for every url in the feed. So, if a feed has three URLs, every twt is associated with three hashes when it comes time to put threads together.

A client stills need to choose one url to use for the hash when composing a reply, but this might add some breathing room if there’s a period when clients are doing different things.

(From what I understand of jenny, this would be difficult to implement there since each pseudo-email can only have one msgid to match to the in-reply-to headers. I don’t know about other clients.)

@bender@twtxt.net Yes, they do 🤣 Implicitly, or threading would never work at all 😅 Nor lookups 🤣 They are used as keys. Think of them like a primary key in a database or index. I totally get where you’re coming from, but there are trade-offs with using Message/Thread Ids as opposed to Content Addressing (like we do) and I believe we would just encounter other problems by doing so.

My money is on extending the Twt Subject extension to support more (optional) advanced “subjects”; i.e: indicating you edited a Twt you already published in your feed as @falsifian@www.falsifian.org indicated 👌

Then we have a secondary (bure much rarer) problem of the “identity” of a feed in the first place. Using the URL you fetch the feed from as @lyse@lyse.isobeef.org ’s client tt seems to do or using the # url = metadata field as every other client does (according to the spec) is problematic when you decide to change where you host your feed. In fact the spec says:

Users are advised to not change the first one of their urls. If they move their feed to a new URL, they should add this new URL as a new url field.

See Choosing the Feed URL – This is one of our longest debates and challenges, and I think (_I suspect along with @xuu@txt.sour.is _) that the right way to solve this is to use public/private key(s) where you actually have a public key fingerprint as your feed’s unique identity that never changes.

@movq@www.uninformativ.de @prologic@twtxt.net Another option would be: when you edit a twt, prefix the new one with (#[old hash]) and some indication that it’s an edited version of the original tweet with that hash. E.g. if the hash used to be abcd123, the new version should start “(#abcd123) (redit)”.

What I like about this is that clients that don’t know this convention will still stick it in the same thread. And I feel it’s in the spirit of the old pre-hash (subject) convention, though that’s before my time.

I guess it may not work when the edited twt itself is a reply, and there are replies to it. Maybe that could be solved by letting twts have more than one (subject) prefix.

But the great thing about the current system is that nobody can spoof message IDs.

I don’t think twtxt hashes are long enough to prevent spoofing.

All this hash breakage made me wonder if we should try to introduce “message IDs” after all. 😅

But the great thing about the current system is that nobody can spoof message IDs. 🤔 When you think about it, message IDs in e-mails only work because (almost) everybody plays fair. Nothing stops me from using the same Message-ID header in each and every mail, that would break e-mail threading all the time.

In Yarn, twt hashes are derived from twt content and feed metadata. That is pretty elegant and I’d hate see us lose that property.

If we wanted to allow editing twts, we could do something like this:

2024-09-05T13:37:40+00:00   (~mp6ox4a) Hello world!

Here, mp6ox4a would be a “partial hash”: To get the actual hash of this twt, you’d concatenate the feed’s URL and mp6ox4a and get, say, hlnw5ha. (Pretty similar to the current system.) When people reply to this twt, they would have to do this:

2024-09-05T14:57:14+00:00	(~bpt74ka) (<a href="https://txt.sour.is/search?q=%23hlnw5ha">#hlnw5ha</a>) Yes, hello!

That second twt has a partial hash of bpt74ka and is a reply to the full hash hlnw5ha. The author of the “Hello world!” twt could then edit their twt and change it to 2024-09-05T13:37:40+00:00 (~mp6ox4a) Hello friends! or whatever. Threading wouldn’t break.

Would this be worth it? It’s certainly not backwards-compatible. 😂

The actual end-user problem is that I can’t see the thread properly when using neomutt+jenny.

@prologic@twtxt.net How does yarn.social’s API fix the problem of centralization? I still need to know whose API to use.

Say I see a twt beginning (#hash) and I want to look up the start of the thread. Is the idea that if that twt is hosted by a a yarn.social pod, it is likely to know the thread start, so I should query that particular pod for the hash? But what if no yarn.social pods are involved?

The community seems small enough that a registry server should be able to keep up, and I can have a couple of others as backups. Or I could crawl the list of feeds followed by whoever emitted the twt that prompted my query.

I have successfully used registry servers a little bit, e.g. to find a feed that mentioned a tag I was interested in. Was even thinking of making my own, if I get bored of my too many other projects :-)

@movq@www.uninformativ.de I think I have got it, but need to test upon receiving further posts. I added:

set uncollapse_new     = yes  # open threads when new mail
set uncollapse_jump    = yes  # jump to unread message when uncollapse
set collapse_unread    = no   # don't collapse threads with unread mails

Let’s see how it goes.

Collapsed threads, that is. If I un-collapse a thread, new/unread messages show on the intended new colour, but while the thread is in collapsed state, there is no highlight.

@bender@twtxt.net, cool, so I can join the threads, but your edit to the original will never show at my end. Will have @bender@twtxt.net show the screenshot.

Testing this. I will break this thread purposely, to see how to handle it under neomutt.

Testing this. I will break this thread purposely, to see how to handle it under neomutt. I have now edited this one. Let’s go!

For the mutt/neomutt users out here, what’s the trick to highlight threads with new messages? No user interaction, just upon opening, or while opened, have threads with new, unread messages in it highlighted. Thanks!

@movq@www.uninformativ.de, using the branch on topic right now, it works perfect. The only thing I found was that I had to quit neomutt, and re-open, to see the perfect thread. Other than that, I love it!

@falsifian@www.falsifian.org @bender@twtxt.net I pushed an alternative implementation to the fetch-context branch. This integrates the whole thing into mutt/jenny.

You will want to configure a new mutt hotkey, similar to the “reply” hotkey:

macro index,pager <esc>C "\
<enter-command> set my_pipe_decode=\$pipe_decode nopipe_decode<Enter>\
<pipe-message> jenny -c<Enter>\
<enter-command> set pipe_decode=\$my_pipe_decode; unset my_pipe_decode<Enter>" \
"Try to fetch context of current twt, like a missing root twt"

This pipes the mail to jenny -c. jenny will try to find the thread hash and the URL and then fetch it. (If there’s no URL or if the specific twt cannot be found in that particular feed, it could query a Yarn pod. That is not yet implemented, though.)

The whole thing looks like this:

https://movq.de/v/0d0e76a180/jenny.mp4

In other words, when there’s a missing root twt, you press a hotkey to fetch it, done.

I think I like this version better. 🤔

(This needs a lot of testing. 😆)

This has become quite a large thread. 😅

https://movq.de/v/5c51be2cd3/s.png

@movq@www.uninformativ.de Is there a good way to get jenny to do a one-off fetch of a feed, for when you want to fill in missing parts of a thread? I just added @slashdot@feeds.twtxt.net to my private follow file just because @prologic@twtxt.net keeps responding to the feed :-P and I want to know what he’s commenting on even though I don’t want to see every new slashdot twt.

Threads Gaining Support for Analytics, Scheduling Posts, Multiple Drafts and More
Threads, Meta’s social network that’s meant to rival X, today announced several new features that are available or coming soon. For creators, Threads is launching analytics for performance measurement.

Image

Users can see view numbers, replies, reposts, an … ⌘ Read more

Fixed so that when you hit ‘reply’ on a post - it adds the already mentioned people in the post (excluding yourself). Makes it much easier to reply properly to a thread.

@bender@twtxt.net He is running on the latest macbook pro with 128G memory. though the chrome app seems to be sitting at 125MB. i am a bit suspicious about that stat since we dont see all the worker threads and he is currently sitting on 40GB of non cache ram.

Apple’s Latest Macs and iPads Have Hidden Smart Home Thread Radio
Apple has added an unannounced Thread radio in most of the Macs and iPads that have been released in the last eight months, according to a report from The Verge. Thread is not listed as a feature in the specifications for the devices released since September 2023, but FCC reports suggest that a Thread radio is indeed included.

![](https://images.macrumors. … ⌘ Read more

Started writing something from scratch yesterday using thread(3) and wow do I miss writing in Limbo instead. :-/ #plan9

Go 的線程池和協程池，看這一篇你就懂了
Golang 線程池與協程池是併發編程中的重要概念，它們可以幫助我們更高效地管理併發任務，提高程序的性能和資源利用率。下面我將詳細解釋這兩個概念，包括它們的實現方式、使用場景以及原理。線程池（Thread Pool）概念：線程池是一種併發設計模式，用於管理線程的創建、銷燬和複用。線程池維護着多個線程，這些線程可以被用來執行任務，任務完成後線程並不立即銷燬，而是返回線程池中等待下一個任務。這樣可以減 ⌘ Read more

What Does the Bell with Line Through It Mean in Messages? Bell Icon on iPhone, iPad, & Mac Explained
You may occasionally see a Messages thread or a conversation in Messages app that shows a bell with a line through it next to the persons name. If you’re wondering what the bell with a line through it means in Messages app, which is the mute symbol, you’re certainly not alone, because not everyone activates … [Read More](https://osxdaily.com/2024/04/05/what-does-bell-line-through-it-m … ⌘ Read more

Arduino Nano Matter: Integrated with BLE and Thread Connectivity
The Arduino Nano Matter, developed in collaboration with Silicon Labs, features the high-performance MGM240S Arm Cortex M33 MCU. Supporting Bluetooth Low Energy and Thread for 802.15.4 connectivity, it’s designed for ease of use with Matter-compatible devices, streamlining rapid prototyping through its user-friendly software. The Arduino Nano Matter is powered by a robust 78 MHz, 32-bit […] ⌘ Read more

ePulse Feather C6: A RISC-V Powered Board with Advanced Zigbee, Thread, and BLE Connectivity
The ePulse Feather C6 by ThingPulse distinguishes itself in the ESP32-C6 development board category, supporting an array of communication protocols including Wi-Fi, BLE, Zigbee, Thread, and Matter. Its low power consumption and flexible power input make it suitable for a wide range of IoT applications. At its core, the ePulse Feather C6 features the ESP32-C6-MI … ⌘ Read more

Not making THREADING the default view of e-mail clients and thus teaching users that e-mail is “chaotic” (if you get a lot of mail, it becomes unusable without threading) and “needs” full quoting all the time was one of the worst mistakes ever.

SolidRun’s First x86-based COM Express 7 Module Taps Ryzen V3000 Embedded V3C48 Processor
SolidRun’s latest Ryzen V3000 CX7 COM Module, with an 8-core/16-thread Ryzen Embedded V3C48 Processor and AMD’s 6nm ‘Zen3’ architecture, marks their entry into x86-based COM Express 7 modules, combining high performance and energy efficiency. The Ryzen V3000 CX7 COM Module from SolidRun features powerful AMD Ryzen processors (V3C18I, V3C48, or optional R7000 7840HS a … ⌘ Read more

ESP32-H2-DEV-KIT-N4: A $5.99 Development Board Featuring a 96MHz RISC-V 32-bit Core
“Waveshare recently introduced the ESP32-H2-DEV-KIT-N4, a compact and versatile microcontroller development board equipped with essential connectivity features like Zigbee, Thread, and Bluetooth. Ideal for various applications including smart homes and other IoT projects. The board, centered around the ESP32-H2-MINI-1 module, features a RISC-V 32-bit single-core processor with a … ⌘ Read more

SparkFun Thing Plus Adopts ESP32-C6 Module with Thread + Zigbee Support
The SparkFun ESP32-C6 Thing Plus, a compact and robust development board, is ideal for innovators looking to craft advanced wireless projects like smart home devices, wireless sensor networks, or other IoT applications. Additionally, it provides support for Arduino IDE, simplifying the software development process. At the heart of the SparkFun ESP32-C6 Thing Plus is the […] ⌘ Read more

Twtxt spec enhancement proposal thread 🧵

Adding attributes to individual twts similar to adding feed attributes in the heading comments.

https://git.mills.io/yarnsocial/go-lextwt/pulls/17

The basic use case would be for multilingual feeds where there is a default language and some twts will be written a different language.

As seen in the wild: https://eapl.mx/twtxt.txt

The attributes are formatted as [key=value]

They can show up in the twt anywhere it is not enclosed by another element such as codeblock or part of a markdown link.

@sorenpeter@darch.dk this makes sense as a quote twt that references a direct URL. If we go back to how it developed on twitter originally it was RT @nick: original text because it contained the original text the twitter algorithm would boost that text into trending.

i like the format (#hash) @<nick url> > "Quoted text"\nThen a comment
as it preserves the human read able. and has the hash for linking to the yarn. The comment part could be optional for just boosting the twt.

The only issue i think i would have would be that that yarn could then become a mess of repeated quotes. Unless the client knows to interpret them as multiple users have reposted/boosted the thread.

The format is also how iphone does reactions to SMS messages with +number liked: original SMS

DFRobot Coin-Sized ESP32-C6 Board with RISC-V Core, Priced at $4.90
The Beetle ESP32-C6 is a compact and versatile IoT development board by DFRobot, designed for Arduino enthusiasts and developers looking to explore low-power IoT solutions. This tiny gizmo offers up to 16x I/Os and an array of communication protocols including Wi-Fi 6, Bluetooth 5, Zigbee 3.0, and Thread 1.3. This device utilizes the same Espressif […] ⌘ Read more

FireBeetle 2 Upgraded with RISC-V Based ESP32-C6 SoC Featuring Zigbee 3.0 and Thread 1.3 Connectivity
DFRobot has announced the launch of the updated FireBeetle 2, now incorporating the latest ESP32-C6 System-on-Chip from Espressif Systems. This enhanced development board integrates standard I/Os, includes comprehensive battery support, and offers advanced connectivity options with Zigbee 3.0 and Thread 1.3. Unlike the FireBeetle 2 (ESP32-S3) … ⌘ Read more

How to Delete a Threads Account Without Leaving Instagram
When Threads debuted from Meta (FaceBook), it was intricately linked to Instagram, and initially when you went to delete or deactivate a Threads account, it had the unfortunate side effect of also deleting the related Instagram account. But that is no longer the case. Now you can choose to delete a Threads account without impacting … [Read More](https://osxdaily.com/2023/12/31/how-to-delete-a-threads-account-without-le … ⌘ Read more

Decided to block the threads.net domain on Mastodon. I am happy with reaching the people that are part of the current Fediverse. I have no need to add more celebrities and brands and whatever to the Mastodon instance I have been enjoying.

@movq@www.uninformativ.de It took a little over a minute on my machine.. i should try to make it multi threaded.. 🤔

Executed in   68.96 secs    fish           external
   usr time   60.84 secs  242.00 micros   60.84 secs
   sys time   12.52 secs  252.00 micros   12.52 secs

… it just finished and brute-force worked. 18 minutes of computing time on my 11 year old machine, single-threaded.

So far it all seems prey snappy. No long pauses when pulling up threads at all.

Run Threads on Desktop with Mac, Windows PC, Linux
Threads, the social network microblogging Twitter/X competitor launched by Meta (Facebook), is typically thought of as a mobile only experience, with users having the Threads app on their iPhone or Android device. But, if you have a Mac, Windows PC, or Linux computer, and you want to use Threads on your desktop computer, you can … Read More ⌘ Read more

@prologic@twtxt.net was this in reply to a different thread? Or maybe a hash collision?

Threads is following Twitter by getting rate limits and all that good stuff.. hahaha

Image

so. if you join threads (meta’s new twitter clone) - then you cannot leave without nuking your instagram..

Interesting thoughts about multi thread vs single thread performance.

Time to dive into threading and c++. I will start with making the file/image downloader threaded, then I’ll make the timeline fetching and all that threaded as well.

I need to add multithreading to the desktop client, I have not done that before in c++ - so that’ll be fun to figure out. I need it for the fetching of the timeline so that it happens in a separate thread. That way the GUI does not freeze while fetching the timeline. Also need to add a status bar that can show what the application is working on.

What is a good device for home virtualization these days? I have been looking at the Intel NUC 13 pro’s. Basically I want something “quiet” (ie not a screaming banshee 1U), smallish, but with lots of threads and rams. Disk will come from an external NAS.

the next thing to fix is thread view, and the reply to.. feature (showing the text preview of the post the reply goes to).

I need to add ‘thread view’ in the Yarn desktop client, I find my self really missing that when I use it. It will make it much easier to follow threads and such.

@xuu@txt.sour.is @prologic@twtxt.net Yarn.social without threading (as it would be the case in a “truncated” feed) does not make sense to me.

Put another way: Yarn.social is not twtxt. The content that we all have in our feeds really is much closer to a web forum or usenet or whatever. It’s threaded conversations. twtxt, as I believe it was originally intended, are short little status updates – that’s it. The formats of Yarn.social and twtxt might be very similar, but the content is vastly different and, in a way, incompatible. (As such, I think I understand very well that the original twtxt crowd is disgruntled.)

That proposed truncated feed doesn’t really provide any value, if you ask me. 🤔 It’d just be chaotic.

One thing I need to also fix - is the way a reply is done, I need it to add the mentions as well, so that you can reply to a person more easily, instead of just the thread.

And threads would be nice to see as well, the list goes on and on :)

📣 Update on Activity Pub: Just a quick update on the Yarn.social <-> Activity Pub (aka Mastodon and others):

• Can follow other Activity Pub actors ✅
  
• Can be followed by other Activity Pub actors ✅
  
• Your posts can be seen by Activity Pub actors ✅
  
• You can see posts from Activity Pub actors ✅
  

What does not yet work:

• Translating replies (aka threading) ❌

I maintain keys for my email addresses.. but like most in this thread i almost never receive encrypted emails.. other than the BTC exchange i use that sends automated mail encrypted.

reading reddit thread about advice for women fighting men rn, and one of the advices is to yank an eye out, not considering that eyes are pretty hard to yank out

The name niplav is based on a roof tile of the University of Maryland, which matches the sequence number and neuroscience thread index, which is how neuroscience researchers manage their data.

There are too many threads going, I can’t keep up. Can someone catch me up on what’s been going on here since last night?

Video: C Programming on System 6 - A Cooperative Threading Library
I’m starting on a new project and I needed a cooperative threading mechanism which didn’t exist in System 6, so I created one. ⌘ Read more

Lossless Image Compression in O(n) Time
Introducing QOI — the Quite OK Image Format. It losslessly compresses RGB and
RGBA images to a similar size of PNG, while offering a 20x-50x speedup in
compression and 3x-4x speedup in decompression. All single-threaded, no
SIMD. It’s also stupidly simple.

tl;dr: 300 lines of C, single header,
source on github,
benchmark results here.

![QOI compression](/content/a … ⌘ Read more

Wob3.11 is a scam. Pass it on. https://threadreaderapp.com/thread/1455625844504743938.html

I like how Slack preserve /me from IRC, but why is it disabled in threads ?

@movq@www.uninformativ.de No argument that threading is an improvement. But I think (#hash) does that, and I think figuring out how to search should mostly be up to the client.

@prologic@twtxt.net we would want:

• a way to reply to the current thread. We have this.
  
• a way to reply to a specific twt. Need this. Maybe make all the replies start new conversations?
  
• check if twt is start of a conversation.. we kinda have this in the main feed with the conversation button. need to extend it for forked convs
  
• a way to inline first replies. maybe show one or two in the sub thread with a link to view.
  
• for convenience have a link to parent conv?

From a /r/4chan thread: “Birth is the ultimate rape.”

@prologic@twtxt.net Testing if this will be added to the thread just adding the hashtag. #utwnv7q

@prologic@twtxt.net Testing if this will be added to the thread just adding the hashtag. #utwnv7q

“Which is for people, that is for people and objects.” -> From a /lit/ thread.

@prologic@twtxt.net what is the exact syntax neeed for threads to work in the subject, e.g. will (#tsvhqdq) do it? The whole … (#tsvhqdq) thing seems like a bit of overkill. Too many characters.

I wish I could do this with @withKnown - A New Way to Publish Your Blog Posts Simultaneously as Twitter Threads ⌘ https://wordpress.com/blog/2020/10/13/a-new-way-to-publish-your-blog-posts-simultaneously-as-twitter-threads/

Posted to Entropy Arbitrage: Experimenting with Worker Threads https://john.colagioia.net/blog/2020/04/15/worker.html #techtips #programming #javascript #threads