Don’t forget about the upcoming Yarn.social monthly online meetup. See #jjbnvgq for details.
Critical Unauthenticated RCE Flaw Impacts All GNU/Linux Systems
“Looks like there’s a storm brewing, and it’s not good news,” writes ancient Slashdot reader jd. “Whether or not the bugs are classically security defects or not, this is extremely bad PR for the Linux and Open Source community. It’s not clear from the article whether this affects other Open Source projects, such as FreeBSD.” From a report: A critical … ⌘ Read more
Last day to have your say before our monthly online meetup 👋
I’d like to see them fine me 2% of zero dollars
@david@collantes.us having offsets were nice because it gives you context of where the user is in relation to you.
@prologic@twtxt.net thanks. I hate it. Might as well use UUID
On:
3.4 Multi-Line Twts: What exactly do you think are bad things with multi-lines?
OP doesn’t want/like markdown (or some of it). He believes multi-lines propitiates or, rather, encourages it.
@lyse@lyse.isobeef.org thank you! Raining is starting to fall very steadily. All good so far. Wife’s home, a nice meal simmers. Ah! :-D
@david@collantes.us Enjoy the day off and fingers crossed that you survive without damages. Stay safe!
Hurricane Helene is passing by. Close enough to give us a day off tomorrow, but not that close to cause major harm. Well, we think. Hurricanes often have a mind of their own, and decide changes on their path. Either way, I shall be back at work on Friday 😩. LOL.
@lyse@lyse.isobeef.org on this:
3.2 Timestamps: I feel no need to mandate UTC. Timezones are fine with me. But I could also live with this new restriction. I fail to see, though, how this change would make things any easier compared to the original format.
Exactly! If anything it will make things more complicated, no?
Good writeup, @anth@a.9srv.net! I agree to most of your points.
3.2 Timestamps: I feel no need to mandate UTC. Timezones are fine with me. But I could also live with this new restriction. I fail to see, though, how this change would make things any easier compared to the original format.
3.4 Multi-Line Twts: What exactly do you think are bad things with multi-lines?
4.1 Hash Generation: I do like the idea with with a new uuid
metadata field! Any thoughts on two feeds selecting the same UUID for whatever reason? Well, the same could happen today with url
.
5.1 Reply to last & 5.2 More work to backtrack: I do not understand anything you’re saying. Can you rephrase that?
8.1 Metadata should be collected up front: I generally agree, but if the uuid
metadata field were a feed URL and no real UUID, there should be probably an exception to change the feed URL mid-file after relocation.
I passed a mountainbiker with a helmet camera in the forst, saw a four centimeter long black beetle that rolled over its side to change directions and finally spotted three deer on the paddock. An hour well spent I reckon.
I might actually end up doing this excercise with our apprentices at work. You can use this as a starting point to teach a ton of things. 🤔
@anth@a.9srv.net you wrote:
“Edits and Deletions should go; see also Section 6. This is probably the worst example of this document pushing a text document to do more protocol-like things.”
Edit and deletions are precisely what brought us here. Currently, if one replies to a twtxt, and the original gets later edited, it breaks replies, and potentially drastically changes context.
Tiens, je découvre qu’il y a un magasin wikimedia: https://store.wikimedia.org/en-fr
@anth@a.9srv.net Thank you I’ll have a read 👌
This is only first draft quality, but I made some notes on the #twtxt v2 proposal. http://a.9srv.net/b/2024-09-25
@sorenpeter@darch.dk i’m just saying that your argument, better support better clients and worrying less about the actual underlying raw Twtxt feed. so the simplicity argument is a bit weaker here.
why can we both have a format that you can write by hand and better clients?
@sorenpeter@darch.dk This is an argument for better clients really and less worry about the “transport” – the raw Twtxt feed file.
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).
@sorenpeter@darch.dk CPU cost of calculating hashes are negligible
Actually, I stand corrected. It shows a reply to a twtxt both having the same date/timestamp.
No, json is overhead. I love twtxt for simplicity where blog is just text file and not several json files where fields are repeated…
yes that works
@sorenpeter@darch.dk not even this: https://twtxt.net/media/AzUmzTN5YEJdt4VPeeprjB.png?full=1
@sorenpeter@darch.dk this will show broken, because you are hellbent on editing twtxts, aren’t you? :-D
@sorenpeter@darch.dk right click, open on new tab, zoom if needed. If shows how the location addressing increases the size on each twtxt.
(#2024-09-24T12:53:35Z) What does this screenshot show? The resolution it too low for reading the text…
(#abcdefg12345)
to something like (https://twtxt.net/user/prologic/twtxt.txt 2024-09-22T07:51:16Z)
.
(#2024-09-24T12:45:54Z) @prologic@twtxt.net I’m not really buying this one about readability. It’s easy to recognize that this is a URL and a date, so you skim over it like you would we mentions and markdown links and images. If you are not suppose to read the raw file, then we might a well jam everything into JSON like mastodon
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).
(#2024-09-24T12:44:35Z) There is a increase in space/memory for sure. But calculating the hashes also takes up CPU. I’m not good with that kind of math, but it’s a tradeoff either way.
(#2024-09-24T12:39:32Z) @prologic@twtxt.net It might be simple for you to run echo -e "\t\t" | sha256sum | base64
, but for people who are not comfortable in a terminal and got their dev env set up, then that is magic, compared to the simplicity of just copy/pasting what you see in a textfile into another textfile – Basically what @movq@www.uninformativ.de also said. I’m also on team extreme minimalism, otherwise we could just use mastodon etc. Replacing line-breaks with a tab would also make it easier to handwrite your twtxt. You don’t have to hardwrite it, but at least you should have the option to. Just as i do with all my HTML and CSS.
yarnd
supports the use of WebMentions, it's very rarely used in practise (if ever) -- In fact I should just drop the feature entirely.
(#2024-09-24T12:34:31Z) WebMentions does would work if we agreed to implement it correctly. I never figured out how yarnd’s WebMentions work, so I decide to make my own, which I’m the only one using…
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.
Finally! After hours I figured out my problems.
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 totrue
got now in my way, this caused a conversation to be removed. Simply deleting all the code around that flag solved it.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.
@lyse@lyse.isobeef.org aha! Just like Bash would do. I figure --
is way too broad to start an autocomplete. Got to feed it a bit more! :-D
@lyse@lyse.isobeef.org Haha 😝
@prologic@twtxt.net Ta! Somehow, my unit tests break, though. Running the same query manually looks like it’s producing a plausible looking result, though. I do not understand it.
@david@collantes.us As far as I understand it, auto-completion is working, that’s the issue. :-D Instead of spamming the terminal with bucketloads of possibilities, zsh’s auto-complete is nice enough to ask whether to proceed or not.
-P
is a life saver when running rsync
over spotty connections. In my very illiterate opinion, it should always be a default.
@david@collantes.us Weird, I always thought that rsync automatically resumes the up- or download when aborted. But the manual indicates otherwise with --partial
(-P
is --partial --progress
).
@prologic@twtxt.net I reckon, I could just hash the subject internally to get a shorter version.
rsync -zaXAP
is what I use all the time. But that’s all – for the rest, I have to consult the manual. 😅
lol, this flags looks like russian name
rsync -avzr
with an optional --progress
is what I always use. Ah, I could use the shorter -P
, thanks @movq.
@lyse@lyse.isobeef.org that -P
is a life saver when running rsync
over spotty connections. In my very illiterate opinion, it should always be a default.
@lyse@lyse.isobeef.org Now increase the indexes on the Twt Subject form 7 bytes to 64 bytes 😈
@lyse@lyse.isobeef.org Congrats 🙌
Hmm this question has a leading “Yes” in favor of so far with 13 votes:
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 🤞)
Three feeds (prologic, movq and mine) and my database is already 1.3 MiB in size. Hmm. I actually got the read filter working. More on that later after polishing it.
Starting a couple of new projects (geez where do I find the time?!):
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(1)
but, whenever I Tab
for completion and get this:
@aelaraji@aelaraji.com I think all replies are missing the fact that your auto-completion isn’t working. LOL. Or did I misunderstood?
rsync(1)
but, whenever I Tab
for completion and get this:
@aelaraji@aelaraji.com @mckinley@twtxt.net rsync -avzr
with an optional --progress
is what I always use. Ah, I could use the shorter -P
, thanks @movq@www.uninformativ.de.