I had a look at WebSub, witch looks way more complex than WebMentions, and seem to need a lot more overhead. We don't need near realtime. We just need a way to notify someone that someone they don't know about mentioned or replied to their post.
I had a look at WebSub, witch looks way more complex than WebMentions, and seem to need a lot more overhead. We don't need near realtime. We just need a way to notify someone that someone they don't know about mentioned or replied to their post.
I had a look at WebSub, witch looks way more complex than WebMentions, and seem to need a lot more overhead. We don't need near realtime. We just need a way to notify someone that someone they don't know about mentioned or replied to their post.
I had a look at WebSub, witch is way more complex than WebMentions, and seem to need a lot more overhead. We don't need near realtime. We just need a way to notify someone that someone they don't know about mentioned or replied to their post.
I had a look at WebSub, witch looks way more complex than WebMentions, and seem to need a lot more overhead. We don't need near realtime. We just need a way to notify someone that someone they don't know about mentioned or replied to their post.
I had a look at WebSub, witch is way more complex than WebMentions, and seem to need a lot more overhead. We don't need near realtime. We just need a way to notify someone that someone they don't know about mentioned or replied to their post.
I had a look at WebSub, witch looks way more complex than WebMentions, and seem to need a lot more overhead. We don't need near realtime. We just need a way to notify someone that someone they don't know about mentioned or replied to their post.
I had a look at WebSub, witch looks way more complex than WebMentions, and seem to need a lot more overhead. We don't need near realtime. We just need a way to notify someone that someone they don't know about mentioned or replied to their post.
1. The clever Go code to filter out completely read conversations got in the way with the filtering now moved into SQL. Yeah, I also did not think that this could ever conflict. But it did. Initializing the
completeConversationRead flag to true got now in my way, this caused a conversation to be removed. Simply deleting all the code around that flag solved it.2. Generation of missing conversation roots in SQL simply used the oldest (smallest) timestamp from any direct reply in the tree. To find the missing roots I grouped by subject and then aggregated using
min(created_at). Now that I optimized this to only take unread messages into consideration in the first place, I do not necessarily see the smallest child anymore (when it's already read), so the timestamp is then moved forward to the next oldest unread reply. As I do not care too much about an accurate timestamp for something made up, I just adjusted my test case accordingly. Good enough for me. :-)It's an interesting experiment with SQLite so far. I certainly did learn a few things along the way. Mission accomplished.
-- is way too broad to start an autocomplete. Got to feed it a bit more! :-D
-- is way too broad to start an autocomplete. Got to feed it a bit more! :-D
--partial (-P is --partial --progress).
-P is a life saver when running rsync over spotty connections. In my very illiterate opinion, it should always be a default.
-P is a life saver when running rsync over spotty connections. In my very illiterate opinion, it should always be a default.
> Should we formally support edit and deletion requests?
Thanks y'all for voting (_it's all anonymous so I have no idea who's voted for what!_)
If you haven't already had your say, please do so here: http://polljunkie.com/poll/xdgjib/twtxt-v2 -- This is my feeble attempt at trying to ascertain the voice of the greater community with ideas of a Twtxt v2 specification (_which I'm hoping will just be an improved specification of what we largely have already built to date with some small but important improvements 🤞_)_
> Should we formally support edit and deletion requests?
Thanks y'all for voting (_it's all anonymous so I have no idea who's voted for what!_)
If you haven't already had your say, please do so here: http://polljunkie.com/poll/xdgjib/twtxt-v2 -- This is my feeble attempt at trying to ascertain the voice of the greater community with ideas of a Twtxt v2 specification (_which I'm hoping will just be an improved specification of what we largely have already built to date with some small but important improvements 🤞_)_
HomeTunnel:
> HomeTunnel is a self-hosted solution that combines secure tunneling, proxying, and automation to create your own private cloud. Utilizing Wireguard for VPN, Caddy for reverse proxying, and Traefik for service routing, HomeTunnel allows you to securely expose your home network services (such as Gitea, Poste.io, etc.) to the Internet. With seamless automation and on-demand TLS, HomeTunnel gives you the power to manage your own cloud-like environment with the control and privacy of self-hosting.
CraneOps:
> craneops is an open-source operator framework, written in Go, that allows self-hosters to automate the deployment and management of infrastructure and applications. Inspired by Kubernetes operators, CraneOps uses declarative YAML Custom Resource Definitions (CRDs) to manage Docker Swarm deployments on Proxmox VE clusters.
HomeTunnel:
> HomeTunnel is a self-hosted solution that combines secure tunneling, proxying, and automation to create your own private cloud. Utilizing Wireguard for VPN, Caddy for reverse proxying, and Traefik for service routing, HomeTunnel allows you to securely expose your home network services (such as Gitea, Poste.io, etc.) to the Internet. With seamless automation and on-demand TLS, HomeTunnel gives you the power to manage your own cloud-like environment with the control and privacy of self-hosting.
CraneOps:
> craneops is an open-source operator framework, written in Go, that allows self-hosters to automate the deployment and management of infrastructure and applications. Inspired by Kubernetes operators, CraneOps uses declarative YAML Custom Resource Definitions (CRDs) to manage Docker Swarm deployments on Proxmox VE clusters.
rsync -avzr with an optional --progress is what I always use. Ah, I could use the shorter -P, thanks @movq.
One could argue this is fine, because we're so small and nothing matters, but it's a properly I rely on fairly heavily in
yarnd, a properly that if lost would have significant impact on how yarnd works I think. 🤔
One could argue this is fine, because we're so small and nothing matters, but it's a properly I rely on fairly heavily in
yarnd, a properly that if lost would have significant impact on how yarnd works I think. 🤔
<url> <timestamp> does not for me identify an individual Twt, it only identifies its location, which may or may not have changed since I last saw a version of it hmmm 🧐
<url> <timestamp> does not for me identify an individual Twt, it only identifies its location, which may or may not have changed since I last saw a version of it hmmm 🧐
yarnd and yarns (_the search engine, crawlers and indexer_) kind of hard to reason about.
yarnd and yarns (_the search engine, crawlers and indexer_) kind of hard to reason about.
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?_
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?_
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.
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.
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.
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.
> 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. 🤔
> 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. 🤔
> 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. 🤔
> 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. 🤔
rsync -zaXAP is what I use all the time. But that’s all – for the rest, I have to consult the manual. 😅
rsync -zaXAP is what I use all the time. But that’s all – for the rest, I have to consult the manual. 😅
rsync -zaXAP is what I use all the time. But that’s all – for the rest, I have to consult the manual. 😅
rsync -zaXAP is what I use all the time. But that’s all – for the rest, I have to consult the manual. 😅
(#abcdefg12345) to something like (https://twtxt.net/user/prologic/twtxt.txt 2024-09-22T07:51:16Z).
(#abcdefg12345) to something like (https://twtxt.net/user/prologic/twtxt.txt 2024-09-22T07:51:16Z).
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_).
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_).
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.
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.
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.
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.
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.
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.~
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.~
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.
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.
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.
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.
#running
#running
#running
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~