In-reply-to » (#5jys7ia) @aelaraji Rsync has a ton of options and I probably still haven't scratched the surface, but I was able to memorize the options I actually need for day-to-day work in a relatively short time. I guess I'm the opposite of you, because I don't know any scp(1) options.

@mckinley@twtxt.net I mean, yes! I’ve heard a lot of good things about how efficient of a tool it is for backup and all; and I’m willing to spend the time and learn. It’s just that seeing those +400 possible options was a buzz-kill. 🫣 luckily @lyse and @movq shared their most used options!

⤋ Read More

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

⤋ Read More
In-reply-to » 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 thank you! Raining is starting to fall very steadily. All good so far. Wife’s home, a nice meal simmers. Ah! :-D

⤋ Read More

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.

⤋ Read More
In-reply-to » (#q3ahzlq) Good writeup, @anth! I agree to most of your points.

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

⤋ Read More

Episódio estranho num táxi em Coimbra. Entrei depois de sair do comboio, e o taxista disse-me logo que tinha de pagar em dinheiro porque não tinha MB. Tudo ok, vamos lá. Quando chegámos ao destino, situação bem estranha:

– Ora bem, são 6.70€
– Ok, vou é precisar de fatura
– Ah não, fatura não tenho
– Como assim?
– Não posso passar fatura
– OK, então temos um problema porque eu tenho de declarar a despesa
– Amigo não lhe posso fazer nada, se não quiser não pague
– o_O como? É assim?
– Pois, se quiser não pague e vá à sua vida
– Ok, uma boa tarde para o senhor
– Boa tarde

O senhor não foi nada mal-educado, simplesmente encolheu os ombros. E eu lá fui à minha vida, sem pagar.

⤋ Read More
In-reply-to » (#knryyga) 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.

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

⤋ Read More
In-reply-to » (#knryyga) 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.

why can we both have a format that you can write by hand and better clients?

⤋ Read More

Radxa Reveals Specs for Siengine SE1000-I Single Board Computer with Linux Support
The SiRider S1 is an upcoming industrial-grade single-board computer jointly developed by Radxa, Siengine Technology, and Arm China. It features the Siengine SE1000-I System-on-Chip, a powerful AIoT application processor built using 7nm technology. According to Radxa’s Wiki pages, this SE1000-I SoC has a dual-cluster CPU architecture. The first cluster includes four high-performa … ⌘ Read more

⤋ Read More
In-reply-to » (#knryyga) 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.

@sorenpeter@darch.dk This is an argument for better clients really and less worry about the “transport” – the raw Twtxt feed file.

⤋ Read More
In-reply-to » (#knryyga) 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).

@sorenpeter@darch.dk CPU cost of calculating hashes are negligible

⤋ Read More
In-reply-to » (#j63urka) (#2024-09-24T12:45:54Z) @prologic 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

No, json is overhead. I love twtxt for simplicity where blog is just text file and not several json files where fields are repeated…

⤋ Read More
In-reply-to » (#knryyga) 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).

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

⤋ Read More
In-reply-to » (#knryyga) 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).

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

⤋ Read More
In-reply-to » (#knryyga) 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.

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

⤋ Read More
In-reply-to » (#knryyga) @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.

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

⤋ Read More

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 🤞)

⤋ Read More

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.

⤋ Read More
In-reply-to » (#knryyga) 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.

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

⤋ Read More
In-reply-to » (#knryyga) 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.

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 🧐

⤋ Read More
In-reply-to » (#knryyga) 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.

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.

⤋ Read More
In-reply-to » (#knryyga) 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.

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

⤋ Read More
In-reply-to » (#knryyga) 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.

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

⤋ Read More
In-reply-to » (#rksyfja) @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.)

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

⤋ Read More
In-reply-to » (#knryyga) 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).

@doesnm@doesnm.p.psf.lt 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.

⤋ Read More
In-reply-to » (#knryyga) 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).

Aggred. But reading twtxt in raw form sounds… I can’t do this

⤋ Read More
In-reply-to » Some more arguments for a local-based treading model over a content-based one:

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

⤋ Read More
In-reply-to » Some more arguments for a local-based treading model over a content-based one:

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

⤋ Read More
In-reply-to » Some more arguments for a local-based treading model over a content-based one:

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.

⤋ Read More
In-reply-to » Some more arguments for a local-based treading model over a content-based one:

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.

⤋ Read More
In-reply-to » Some more arguments for a local-based treading model over a content-based one:

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.

⤋ Read More
In-reply-to » Some more arguments for a local-based treading model over a content-based one:

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

⤋ Read More

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.

⤋ Read More

@aelaraji@aelaraji.com Rsync has a ton of options and I probably still haven’t scratched the surface, but I was able to memorize the options I actually need for day-to-day work in a relatively short time. I guess I’m the opposite of you, because I don’t know any scp(1) options.

⤋ Read More

x86 Embedded Controller with PC/104 Compatibility for Legacy Systems
The VDX3-6757 PC/104 family of low-power x86 embedded controllers meets PC/104 specifications, offering backward compatibility for projects facing end-of-life x86-based controllers. It is suited for applications like data acquisition, industrial automation, process control, and automotive control. Powered by a DM&P Vortex86DX3 1GHz dual-core CPU with 32KB L1 cache and 512KB L2 cache, the VDX3-6757 supports … ⌘ Read more

⤋ Read More

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

⤋ Read More
In-reply-to » I’m not writing on 'twtxt' as much as I did in 2021-2022. While it has many advantages, I couldn't get my close circle to join.

@eapl.me@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? 😅

⤋ Read More

Aunque me gusta mucho el concepto descentralizado de ‘twtxt’, este año no lo he utilizado tanto. No pude tener a mi círculo cercano, con quienes surgen las conversaciones que me gustan, y por el que se da un efecto de red significativo.

También estoy buscando un minimalismo digital, utilizando servicios que brinden alegría, valor y un uso de tiempo razonable.
Aunque es un tema controversial, ¿por qué no tener una comunidad de personas con las que sintamos que el mundo (digital al menos) es un lugar mejor?

Quizás un poco idealista el punto, aunque la intención es que el tiempo que pasamos en ‘la red’, nos ayude a crecer como personas, a disfrutar el tiempo, y a vivir esta vida digital con sentido.

Por todo esto, el poco tiempo que esté en microblogging, lo buscaré en las dos plataformas que más conversaciones significativas me generan, que por un lado es X, para todo lo profesional, y Mastodon, para lo hipster, indie, idealista, etc.

Si algo de lo que he compartido por twtxt ha sido importante para ti, o quieres que sigamos charlando, me puedes encontrar en alguna de estas otras plataformas:
https://text.eapl.mx/microblogging

⤋ Read More

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

⤋ Read More
In-reply-to » I'm experimenting with SQLite and trees. It's going good so far with only my own 439 messages long main feed from a few days ago in the cache. Fetching these 632 rows took 20ms:

@lyse@lyse.isobeef.org Yeah I think it’s one of the reasons why yarnd’s cache became so complicated really. I mean it’s a bunch of maps and lists that is recalculated every ~5m. I don’t know of any better way to do this right now, but maybe one day I’ll figure out a better way to represent the same information that is displayed today that works reasonably well.

⤋ Read More
In-reply-to » Another interesting side effect of changing from content-based addressing to location-based addressing is that switching from 7-byte keys to 2025-character keys for 3.5 million entries would expand the database size from 24.5 MB to about 7.09 GB—an increase of roughly 7.06 GB!

My point is, this is not a small trade-off to make for the sake of simplicity 😅

⤋ Read More
In-reply-to » Another interesting side effect of changing from content-based addressing to location-based addressing is that switching from 7-byte keys to 2025-character keys for 3.5 million entries would expand the database size from 24.5 MB to about 7.09 GB—an increase of roughly 7.06 GB!

@movq@www.uninformativ.de Maybe I misspoke. It’s a factor of 5 in the size of the keyspace required. The impact is significantly less for on-disk storage of raw feeds and such, around ~1-1.5x depending on how many replies there are I suppose.

I wasn’t very clear; my apologies. If we update the current hash truncation length from 7 to 11. But then still decide anyway to go down this location-based twt identity and threading model then yes, we’re talking about twt subjects having a ~5x increase in size on average. Going from 14 characters (11 for the has, 2 for the parens, 1 for the #) to ~63 bytes (average I’ve worked out of length of URL + Timestamp) + 3 byte overhead for parents and space.

⤋ Read More
In-reply-to » I'm experimenting with SQLite and trees. It's going good so far with only my own 439 messages long main feed from a few days ago in the cache. Fetching these 632 rows took 20ms:

@lyse@lyse.isobeef.org And your query to construct a tree? Can you share the full query (screenshot looks scary 🤣) – On another note, SQL and relational databases aren’t really that conduces to tree-like structures are they? 🤣

⤋ Read More
In-reply-to » One of the reasons we wanted to originally use Contant based addressing and short hashes as our threading model was to keep individual Twts short so that they were still readable if you viewed the manually by hand.

In fact it depends on how many Twts there are that form part of a thread, if you take a much larger sample size of my own feed for example, it starts to approximate ~1.5x increase in size:

$ ./compare.sh https://twtxt.net/user/prologic/twtxt.txt 500
Original file size: 126842 bytes
Modified file size: 317029 bytes
Percentage increase in file size: 149.94%
...

⤋ Read More
In-reply-to » (#5sdepuq) @lyse I'd suggest making the whole content-type thing a SHOULD, to accommodate people just using some hosting service they don't have much control over. (The same situation could make detecting followers hard, but IMO "please email me if you follow me" is still legit twtxt, even if inconvenient.)

Can someone make the edit?

⤋ Read More