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.

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

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

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

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

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

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.

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

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

lol, this flags looks like russian name

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

@aelaraji@aelaraji.com I think all replies are missing the fact that your auto-completion isn’t working. LOL. Or did I misunderstood?

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

I think that’s one of the worst aspects of the proposed idea of location-based addressing or identity. The fact that Alice reads Twt A and Bob reads Twt A at the same location, but Alice and Bob could have in fact read very different content entirely. It is no longer possible to have consistency in a decentralised way that works properly.

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

Unless I”m missing something here 🤔 But a <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 🧐

Also I’m not even sure I can validly cache, let alone index feeds anymore if we do this, because if the structure of a Twt is cuh that I can no longer trust that an individual Twt’s content hasn’t been changed at the source, what’s the point of caching or indexing individual twts at all? This makes the implementations of yarnd and yarns (the search engine, crawlers and indexer) kind of hard to reason about.

Also you’re right I guess. But still that also requires the author not to change the timestamp too. Hmmm

@movq@www.uninformativ.de I don’t think there’s any misunderstand at all. I just treat every lines in a feed as an individual entity. These are stored on their own.

@movq@www.uninformativ.de 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@twtxt.net 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@doesnm.p.psf.lt Like maybe you need to check something, debug a client, or whatever 😅

@prologic@twtxt.net

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@aelaraji.com rsync -zaXAP is what I use all the time. But that’s all – for the rest, I have to consult the manual. 😅