# I am the Watcher. I am your guide through this vast new twtiverse.
#
# Usage:
# https://watcher.sour.is/api/plain/users View list of users and latest twt date.
# https://watcher.sour.is/api/plain/twt View all twts.
# https://watcher.sour.is/api/plain/mentions?uri=:uri View all mentions for uri.
# https://watcher.sour.is/api/plain/conv/:hash View all twts for a conversation subject.
#
# Options:
# uri Filter to show a specific users twts.
# offset Start index for quey.
# limit Count of items to return (going back in time).
#
# twt range = 1 196266
# self = https://watcher.sour.is?offset=172056
# next = https://watcher.sour.is?offset=172156
# prev = https://watcher.sour.is?offset=171956
@movq So I obviously happen to agree with you as well. However in so saying, one of my goals was also to bring the simplicity of Twtxt to the Web and for the general "lay person" (_of sorts_). So I eventually found myself building yarnd. Has it been successful, well sort of, somewhat (_but that doesn't matter, I like that it's small and niche anyway_).
I agree that the goal of simplicity is a good goal to strive for, which is why I'm actually suggesting we change the Twt identifiers to be a simple SHA256 hash, something that everyone understand and has readily available tools for. I really don't think we should be doing any of this by hand to be honest. But part of the beauty of Twt Subject and Twt Hash(es) in the first place is replying by hand is much much easier because you only have a short 7 or 11 character thing to copy/paste in your reply. Switching to something like <url> <timestamp> with a space in it is going to become a lot harder to copy/paste, because you can't "double click" (_or is it triple click for some?_) to copy/paste to your clipboard/buffer now 🤣
Anyway I digress... On the whole edit thing, I'm actually find if we don't support it at all and don't build a protocol around that. I have zero issues with dropping that as an idea. Why? Because I actually think that clients should be auto-detecting edits anyway. They already can, I've PoC'd this myself, I _think_ it can be done. I haven't (yet), and one of the reasons I've not spent much effort in it is it isn't something that comes up frequently anyway.
Who cares if a thread breaks every now 'n again anyway?_
@prologic When I first started using twtxt, I was fascinated by the fact that it’s just a simple text file. This is already undermined *a lot* today by us using multiline replies and Markdown and what not. Still, I would love to retain this property of it being just a file that needs very few external tools to maintain. (Jenny is quite bloated, one might argue. One of the reasons for even *starting* the jenny project was the calculation of hashes – I was using a smaller, simpler toolchest before.)
If we were to use (replyto:…), I could just copy and paste the required info into my text editor. With echo … | sha256sum | base64 (+ the truncation step), I have to open a new terminal, make sure the tab gets copied verbatim, make sure that there’s no trailing whitespace in the content, little details like that. It *is* more effort.
This probably isn’t the best argument for (replyto:…), but it is *an* argument.
Would people do all this manually? I don’t know. Probably not. But part of the fascination with twtxt is that you *could* do it.
I’m speaking from a point of extreme minimalism here and all this isn’t strictly only related to (reply:…). It just reflects my general view on twtxt. The more additional things we build on top, the less interesting twtxt becomes (for me). My goal would be to find solutions that require *less*. Like, don’t solve edits breaking threads by *adding* another protocol, but by rethinking the whole thing, finding the root cause, and maybe come up with something that doesn’t need another building block on top.
This is all I have to say for now. 😃 I’m gonna let things cool off for a while.
@prologic When I first started using twtxt, I was fascinated by the fact that it’s just a simple text file. This is already undermined *a lot* today by us using multiline replies and Markdown and what not. Still, I would love to retain this property of it being just a file that needs very few external tools to maintain. (Jenny is quite bloated, one might argue. One of the reasons for even *starting* the jenny project was the calculation of hashes – I was using a smaller, simpler toolchest before.)
If we were to use (replyto:…), I could just copy and paste the required info into my text editor. With echo … | sha256sum | base64 (+ the truncation step), I have to open a new terminal, make sure the tab gets copied verbatim, make sure that there’s no trailing whitespace in the content, little details like that. It *is* more effort.
This probably isn’t the best argument for (replyto:…), but it is *an* argument.
Would people do all this manually? I don’t know. Probably not. But part of the fascination with twtxt is that you *could* do it.
I’m speaking from a point of extreme minimalism here and all this isn’t strictly only related to (reply:…). It just reflects my general view on twtxt. The more additional things we build on top, the less interesting twtxt becomes (for me). My goal would be to find solutions that require *less*. Like, don’t solve edits breaking threads by *adding* another protocol, but by rethinking the whole thing, finding the root cause, and maybe come up with something that doesn’t need another building block on top.
This is all I have to say for now. 😃 I’m gonna let things cool off for a while.
@prologic When I first started using twtxt, I was fascinated by the fact that it’s just a simple text file. This is already undermined *a lot* today by us using multiline replies and Markdown and what not. Still, I would love to retain this property of it being just a file that needs very few external tools to maintain. (Jenny is quite bloated, one might argue. One of the reasons for even *starting* the jenny project was the calculation of hashes – I was using a smaller, simpler toolchest before.)
If we were to use (replyto:…), I could just copy and paste the required info into my text editor. With echo … | sha256sum | base64 (+ the truncation step), I have to open a new terminal, make sure the tab gets copied verbatim, make sure that there’s no trailing whitespace in the content, little details like that. It *is* more effort.
This probably isn’t the best argument for (replyto:…), but it is *an* argument.
Would people do all this manually? I don’t know. Probably not. But part of the fascination with twtxt is that you *could* do it.
I’m speaking from a point of extreme minimalism here and all this isn’t strictly only related to (reply:…). It just reflects my general view on twtxt. The more additional things we build on top, the less interesting twtxt becomes (for me). My goal would be to find solutions that require *less*. Like, don’t solve edits breaking threads by *adding* another protocol, but by rethinking the whole thing, finding the root cause, and maybe come up with something that doesn’t need another building block on top.
This is all I have to say for now. 😃 I’m gonna let things cool off for a while.
@prologic When I first started using twtxt, I was fascinated by the fact that it’s just a simple text file. This is already undermined *a lot* today by us using multiline replies and Markdown and what not. Still, I would love to retain this property of it being just a file that needs very few external tools to maintain. (Jenny is quite bloated, one might argue. One of the reasons for even *starting* the jenny project was the calculation of hashes – I was using a smaller, simpler toolchest before.)
If we were to use (replyto:…), I could just copy and paste the required info into my text editor. With echo … | sha256sum | base64 (+ the truncation step), I have to open a new terminal, make sure the tab gets copied verbatim, make sure that there’s no trailing whitespace in the content, little details like that. It *is* more effort.
This probably isn’t the best argument for (replyto:…), but it is *an* argument.
Would people do all this manually? I don’t know. Probably not. But part of the fascination with twtxt is that you *could* do it.
I’m speaking from a point of extreme minimalism here and all this isn’t strictly only related to (reply:…). It just reflects my general view on twtxt. The more additional things we build on top, the less interesting twtxt becomes (for me). My goal would be to find solutions that require *less*. Like, don’t solve edits breaking threads by *adding* another protocol, but by rethinking the whole thing, finding the root cause, and maybe come up with something that doesn’t need another building block on top.
This is all I have to say for now. 😃 I’m gonna let things cool off for a while.
@doesnm Like maybe you need to check something, debug a client, or whatever 😅
@doesnm Like maybe you need to check something, debug a client, or whatever 😅
@prologic
> Location-based addressing is vulnerable to the content changing. If the content changes the "location" is no longer valid. This is a problem if you build systems that rely on this.
What you’re mentioning is *the primary reason*, imho, *for* location-based addressing. You’re referencing a certain entry in a feed by its timestamp and the author is free to edit it. This solves the problem of broken threads after edits. And editing “raw” twtxt files is a very natural thing to do in the twtxt world (just not in *Yarn*’s world). It’s one of the core aspects and main selling points: You just have a file that you can edit with vi or whatever, done.
If you think changing content is a *vulnerability* of location-based addressing, then I get the feeling that there’s some kind of big misunderstanding going on here. 🤔 Either on your end or on mine/ours. 🤔
@prologic
> Location-based addressing is vulnerable to the content changing. If the content changes the "location" is no longer valid. This is a problem if you build systems that rely on this.
What you’re mentioning is *the primary reason*, imho, *for* location-based addressing. You’re referencing a certain entry in a feed by its timestamp and the author is free to edit it. This solves the problem of broken threads after edits. And editing “raw” twtxt files is a very natural thing to do in the twtxt world (just not in *Yarn*’s world). It’s one of the core aspects and main selling points: You just have a file that you can edit with vi or whatever, done.
If you think changing content is a *vulnerability* of location-based addressing, then I get the feeling that there’s some kind of big misunderstanding going on here. 🤔 Either on your end or on mine/ours. 🤔
@prologic
> Location-based addressing is vulnerable to the content changing. If the content changes the "location" is no longer valid. This is a problem if you build systems that rely on this.
What you’re mentioning is *the primary reason*, imho, *for* location-based addressing. You’re referencing a certain entry in a feed by its timestamp and the author is free to edit it. This solves the problem of broken threads after edits. And editing “raw” twtxt files is a very natural thing to do in the twtxt world (just not in *Yarn*’s world). It’s one of the core aspects and main selling points: You just have a file that you can edit with vi or whatever, done.
If you think changing content is a *vulnerability* of location-based addressing, then I get the feeling that there’s some kind of big misunderstanding going on here. 🤔 Either on your end or on mine/ours. 🤔
@prologic
> Location-based addressing is vulnerable to the content changing. If the content changes the "location" is no longer valid. This is a problem if you build systems that rely on this.
What you’re mentioning is *the primary reason*, imho, *for* location-based addressing. You’re referencing a certain entry in a feed by its timestamp and the author is free to edit it. This solves the problem of broken threads after edits. And editing “raw” twtxt files is a very natural thing to do in the twtxt world (just not in *Yarn*’s world). It’s one of the core aspects and main selling points: You just have a file that you can edit with vi or whatever, done.
If you think changing content is a *vulnerability* of location-based addressing, then I get the feeling that there’s some kind of big misunderstanding going on here. 🤔 Either on your end or on mine/ours. 🤔
Sorry but i dont undestand b. New feed author? But why?
@aelaraji rsync -zaXAP is what I use all the time. But that’s all – for the rest, I have to consult the manual. 😅
@aelaraji rsync -zaXAP is what I use all the time. But that’s all – for the rest, I have to consult the manual. 😅
@aelaraji rsync -zaXAP is what I use all the time. But that’s all – for the rest, I have to consult the manual. 😅
@aelaraji rsync -zaXAP is what I use all the time. But that’s all – for the rest, I have to consult the manual. 😅
@lyse Yeah, it’s different for everone. 😅 I, for one, am not particularly interested (yet) in the underlying hardware. Logic gates and stuff like that, that’s not my kind of thing. Maybe in the future, but there’s still more than enough to explore in the world of software. 😃
@lyse Yeah, it’s different for everone. 😅 I, for one, am not particularly interested (yet) in the underlying hardware. Logic gates and stuff like that, that’s not my kind of thing. Maybe in the future, but there’s still more than enough to explore in the world of software. 😃
@lyse Yeah, it’s different for everone. 😅 I, for one, am not particularly interested (yet) in the underlying hardware. Logic gates and stuff like that, that’s not my kind of thing. Maybe in the future, but there’s still more than enough to explore in the world of software. 😃
@lyse Yeah, it’s different for everone. 😅 I, for one, am not particularly interested (yet) in the underlying hardware. Logic gates and stuff like that, that’s not my kind of thing. Maybe in the future, but there’s still more than enough to explore in the world of software. 😃
Don't forget about the upcoming Yarn.social online meetup coming up this Saturday! 😅 See #jjbnvgq for details! -- Hope to see y'all there 💪
Don't forget about the upcoming Yarn.social online meetup coming up this Saturday! 😅 See #jjbnvgq for details! -- Hope to see y'all there 💪
👋 Don't forget to take the Twtxt v2 poll 🙏 if you haven't done so already (_sorry about the confusing question at the end!_)
👋 Don't forget to take the Twtxt v2 poll 🙏 if you haven't done so already (_sorry about the confusing question at the end!_)
@doesnm I don't even advocate for reading Twtxt in its raw form in the first place, which is why I'm in favor of continuing to use content-based addressing (hashes) and incremental improve what we already have. IMO the only reason to read a Twtxt file in it's raw form is a) if you're a developer b) new feed author or c) debugging a client issue.
@doesnm I don't even advocate for reading Twtxt in its raw form in the first place, which is why I'm in favor of continuing to use content-based addressing (hashes) and incremental improve what we already have. IMO the only reason to read a Twtxt file in it's raw form is a) if you're a developer b) new feed author or c) debugging a client issue.
Aggred. But reading twtxt in raw form sounds... I can't do this
And finally the legibility of feeds when viewing them in their raw form are worsened as you go from a Twt Subject of (#abcdefg12345) to something like (https://twtxt.net/user/prologic/twtxt.txt 2024-09-22T07:51:16Z).
And finally the legibility of feeds when viewing them in their raw form are worsened as you go from a Twt Subject of (#abcdefg12345) to something like (https://twtxt.net/user/prologic/twtxt.txt 2024-09-22T07:51:16Z).
There is also a ~5x increase cost in memory utilization for any implementations or implementors that use or wish to use in-memory storage (yarnd does for example) and equally a 5x increase in on-disk storage as well. This is based on the Twt Hash going from a 13 bytes (content-addressing) to 63 bytes (on average for location-based addressing). There is roughly a ~20-150% increase in the size of individual feeds as well that needs to be taken into consideration (_on the average case_).
There is also a ~5x increase cost in memory utilization for any implementations or implementors that use or wish to use in-memory storage (yarnd does for example) and equally a 5x increase in on-disk storage as well. This is based on the Twt Hash going from a 13 bytes (content-addressing) to 63 bytes (on average for location-based addressing). There is roughly a ~20-150% increase in the size of individual feeds as well that needs to be taken into consideration (_on the average case_).
With Location-based addressing there is no way to verify that a single Twt _actaully_ came from that feed without actually fetching the feed and checking. That has the effect of always having to rely on fetching the feed and storing a copy of feeds you fetch (_which is okay_), but you're force to do this. You cannot really share individual Twts anymore really like yarnd does (_as peering_) because there is no "integrity" to the Twt identified by it's <url> <timestamp>. The identify is meaningless and is only valid as long as you can trust the location and that the location at that point hasn't changed its content.
With Location-based addressing there is no way to verify that a single Twt _actaully_ came from that feed without actually fetching the feed and checking. That has the effect of always having to rely on fetching the feed and storing a copy of feeds you fetch (_which is okay_), but you're force to do this. You cannot really share individual Twts anymore really like yarnd does (_as peering_) because there is no "integrity" to the Twt identified by it's <url> <timestamp>. The identify is meaningless and is only valid as long as you can trust the location and that the location at that point hasn't changed its content.
Location-based addressing is vulnerable to the content changing. If the content changes the "location" is no longer valid. This is a problem if you build systems that rely on this.
Location-based addressing is vulnerable to the content changing. If the content changes the "location" is no longer valid. This is a problem if you build systems that rely on this.
So really your argument is just that switching to a location-based addressing "just makes sense". Why? Without concrete pros/cons of each approach this isn't really a strong argument I'm afraid. In fact I probably need to just sit down and detail the properties of both approaches and the pros/cons of both.
I also don't really buy the argument of simplicity either personally, because I don't technically see it much more difficult to take a echo -e "<url>\t<timestamp>\t<content>" | sha256sum | base64 as the Twt Subject or concatenating the <url> <timestamp> -- The "effort" is the same. If we're going to argue that SHA256 or cryptographic hashes are "too complicated" then I'm not really sure how to support that argument.
So really your argument is just that switching to a location-based addressing "just makes sense". Why? Without concrete pros/cons of each approach this isn't really a strong argument I'm afraid. In fact I probably need to just sit down and detail the properties of both approaches and the pros/cons of both.
I also don't really buy the argument of simplicity either personally, because I don't technically see it much more difficult to take a echo -e "<url>\t<timestamp>\t<content>" | sha256sum | base64 as the Twt Subject or concatenating the <url> <timestamp> -- The "effort" is the same. If we're going to argue that SHA256 or cryptographic hashes are "too complicated" then I'm not really sure how to support that argument.
So really your argument is just that switching to a location-based addressing "just makes sense". Why? Without concrete pros/cons of each approach this isn't really a strong argument I'm afraid. In fact I probably need to just sit down and detail the properties of both approaches and the pros/cons of both.
I also don't really buy the argument of simplicity either personally, because I don't technically see it much more difficult to take a echo -e "<url>\\t<timestamp>\\t<content>" | sha256sum | base64 as the Twt Subject or concatenating the <url> <timestamp> -- The "effort" is the same. If we're going to argue that SHA256 or cryptographic hashes are "too complicated" then I'm not really sure how to support that argument.
@sorenpeter 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.~
@sorenpeter 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.~
Some more arguments for a local-based treading model over a content-based one:
1. The format: (#<DATE URL>) or (@<DATE URL>) both makes sense: # as prefix is for a hashtag like we allredy got with the (#twthash) and @ as prefix denotes that this is mention of a specific post in a feed, and not just the feed in general. Using either can make implementation easier, since most clients already got this kind of filtering.
2. Having something like (#<DATE URL>) will also make mentions via webmetions for twtxt easier to implement, since there is no need for looking up the #twthash. This will also make it possible to make 3th part twt-mentions services.
3. Supporting twt/webmentions will also increase discoverability as a way to know about both replies and feed mentions from feeds that you don't follow.
Some more arguments for a local-based treading model over a content-based one:
1. The format: (#<DATE URL>) or (@<DATE URL>) both makes sense: # as prefix is for a hashtag like we allredy got with the (#twthash) and @ as prefix denotes that this is mention of a specific post in a feed, and not just the feed in general. Using either can make implementation easier, since most clients already got this kind of filtering.
2. Having something like (#<DATE URL>) will also make mentions via webmetions for twtxt easier to implement, since there is no need for looking up the #twthash. This will also make it possible to make 3th part twt-mentions services.
3. Supporting twt/webmentions will also increase discoverability as a way to know about both replies and feed mentions from feeds that you don't follow.
Some more arguments for a local-based treading model over a content-based one:
1. The format: (#<DATE URL>) or (@<DATE URL>) both makes sense: # as prefix is for a hashtag like we allredy got with the (#twthash) and @ as prefix denotes that this is mention of a specific post in a feed, and not just the feed in general. Using either can make implementation easier, since most clients already got this kind of filtering.
2. Having something like (#<DATE URL>) will also make mentions via webmetions for twtxt easier to implement, since there is no need for looking up the #twthash. This will also make it possible to make 3th part twt-mentions services.
3. Supporting twt/webmentions will also increase discoverability as a way to know about both replies and feed mentions from feeds that you don't follow.
Some more arguments for a local-based treading model over a content-based one:
1. The format: (#<DATE URL>) or (@<DATE URL>) both makes sense: # as prefix is for a hashtag like we allredy got with the (#twthash) and @ as prefix denotes that this is mention of a specific post in a feed, and not just the feed in general. Using either can make implementation easier, since most clients already got this kind of filtering.
2. Having something like (#<DATE URL>) will also make mentions via webmetions for twtxt easier to implement, since there is no need for looking up the #twthash. This will also make it possible to make 3th part twt-mentions services.
3. Supporting twt/webmentions will also increase discoverability as a way to know about both replies and feed mentions from feeds that you don't follow.
Finally pubnix is alive! That's im missing? Im only reading twtxt.net timeline because twtxt-v2.sh works slowly for displaying timeline...
[47°09′52″S, 126°43′28″W] Bad satellite signal -- switching to analog communication
[47°09′03″S, 126°43′42″W] Storm recedes -- back to normal work
[47°09′47″S, 126°43′53″W] Wind speed: 42kph
🧮 USERS:1 FEEDS:2 TWTS:1102 ARCHIVED:79309 CACHE:2611 FOLLOWERS:17 FOLLOWING:14
Been trying to get acquainted with rsync(1) but, whenever I Tab for completion and get this:
> λ ~/ rsync --
> zsh: do you wish to see all 484 possibilities (162 lines)?
I'm like: Nope! a scp -rpCq ... or whatever option salad will do just fine. 😅 \n~
Been trying to get acquainted with rsync(1) but, whenever I Tab for completion and get this:
> λ ~/ rsync --
> zsh: do you wish to see all 484 possibilities (162 lines)?
I'm like: Nope! a scp -rpCq ... or whatever option salad will do just fine. 😅 [Insert: "Ain't nobody got time fo'that!" Meme.]~
Been trying to get acquainted with rsync(1) but, whenever I Tab for completion and get this:
> λ ~/ rsync --
> zsh: do you wish to see all 484 possibilities (162 lines)?
I'm like: Nope! a scp -rpCq ... or whatever option salad will do just fine. 😅 [Insert: "Ain't nobody got time fo'that!" Meme.]~
experimenting with litefs has been really interesting. i'm still learning about consul, so nothing distributed is happening yet. so far i have a setup that shares a virtual filesystem with a set of nixos containers running ejabberd and redka. soon some ory services for auth and security which also support sqlite will join the party, but those require higher availability that i can manage with my current deployment. the big server needs to me migrated before security can come online.
Syncthing is also as good as everyone says it is.
@movq Interesting, it's always good to know how things work under the hood. But I'm very glad, that I do not have to deal with this low-level stuff. :-)
[47°09′34″S, 126°43′02″W] Wind speed: N/A -- Cannot comunicate
@prologic violent enough to be taken away by the police. 🤭😂
@prologic @movq Luckily, we were only touched by the thunderstorm cell. Even though the sky lit up a bunch and the thunder roared, there were no close thunderbolts. But it rained cats and dogs. The air smelled lovely.
@eapl.me All the best, see you next life around. :-) On Twtxt I only meet my online friends. I'm staying in touch with some of my real life mates on IRC or e-mail. But that's fine. That's just how it goes.
Thanks, @bender. :-)
I know what keeps me coming back to twtxt. It is the little group of people with whom I interact. I don’t need a big audience. More often than not I have nothing interesting to write, but I enjoy the small interactions: bugging prologic, reading abucci, browsing Lyse’s clicks. I enjoy movq commentaries (I imagine him as a professor of some kind, don’t ask me why).
Anyway… cheers!
#catsoftwtxt
#catsoftwtxt
#catsoftwtxt
#catsoftwtxt
@eapl.me are you sure X will bring joy, and value? Will you have clear conscience knowing you are contributing to such despicable platform? It is your decision to make, sure.
Joy starts at you, not the platform you use. When you get bored, disgusted, offended, and leave X, come and let us know. I will be interested to read all about your experiment then. For now, “¡hasta pronto!”
[47°09′01″S, 126°43′17″W] Weather forecast alert -- storm from NE
@movq Yes, the tools are surprisingly fast. Still, magrep takes about 20 seconds to search through my archive of 140K emails, so to speed things up I would probably combine it with an indexer like mu, mairix or notmuch.
@eapl.me Aww. Well, I gave you a Follow on Mastodon (although that appears to be moastly Spanish 🤔).
@eapl.me Aww. Well, I gave you a Follow on Mastodon (although that appears to be moastly Spanish 🤔).
@eapl.me Aww. Well, I gave you a Follow on Mastodon (although that appears to be moastly Spanish 🤔).
@eapl.me Aww. Well, I gave you a Follow on Mastodon (although that appears to be moastly Spanish 🤔).
@falsifian You had me there for a second. 😅
I have to admit, even though I knew they existed, I never had a look at Leah’s mail tools. Just gave mthread a spin and this is crazy fast. 🤯 Tempting!
@falsifian You had me there for a second. 😅
I have to admit, even though I knew they existed, I never had a look at Leah’s mail tools. Just gave mthread a spin and this is crazy fast. 🤯 Tempting!
@falsifian You had me there for a second. 😅
I have to admit, even though I knew they existed, I never had a look at Leah’s mail tools. Just gave mthread a spin and this is crazy fast. 🤯 Tempting!
@falsifian You had me there for a second. 😅
I have to admit, even though I knew they existed, I never had a look at Leah’s mail tools. Just gave mthread a spin and this is crazy fast. 🤯 Tempting!
@eapl.me Sad to see you go, disappointed in your choice of X, but respect your decision and choice. I will never cave in myself, even if it means my "circle of friends" remains low. I guess we call 'em internet friends right? 😅
@eapl.me Sad to see you go, disappointed in your choice of X, but respect your decision and choice. I will never cave in myself, even if it means my "circle of friends" remains low. I guess we call 'em internet friends right? 😅
#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.
@lyse How violent is the thunderstorm? 🤔
@lyse How violent is the thunderstorm? 🤔
We're now having a thunderstorm with rain, lightning and thunder and the severe weather map shows all green. I'd expect it to be violet.
/https://baldo.cat/media/photos/IMG_2115.jpeg) #catsoftwtxt
/https://baldo.cat/media/photos/IMG_2113.jpeg) #catsoftwtxt