“For every complex problem, there is a solution that is clear, simple, and wrong.”

– H.L. Mencken

Also, I’m not editing the original post. 😅

@bender@twtxt.net ha ha yes ideally one day I would love it if Twt hashes referenced at least any yarnd clients were automatically linked. 🤣

“Everything should be made as simple as possible, but not simpler.”
– Albert Einstein

The beauty of simplicity lies in not losing the essence.

#simplicity #Einstein #wisdom

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 👋

http://polljunkie.com/poll/xdgjib/twtxt-v2

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

@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

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?

I hear from sources that Khzae will soon shut down. I hope am wrong.

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.

Um belo verbo encontrado nos meandros do desenvolvimento web: “transpilar”

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

Monthly sign of life. We’re good.

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

https://jacobin.com/2024/09/rashida-tlaib-antisemitism-palestinians-media

(Updated) W55RP20-EVB-PICO: Integrating W5500 TCP/IP Controller and RP2040
W55RP20-EVB-PICO: Integrating W5500 TCP/IP Controller and RP2040 ⌘ Read more

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

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

@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

O meu artigo na #PCGuia sobre o @ardour@ardour saiu em papel há uns meses, mas entretanto também foi disponibilizado digital e gratuitamente - ler é aqui:

https://www.pcguia.pt/2024/08/usar-o-ardour-para-fazer-producao-de-audio/

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 this will show broken, because you are hellbent on editing twtxts, aren’t you? :-D

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

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

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

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?

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?

@doesnm@doesnm.p.psf.lt Like maybe you need to check something, debug a client, or whatever 😅

Sorry but i dont undestand b. New feed author? But why?

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

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

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

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.

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.

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

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.

@doesnm@doesnm.p.psf.lt Welcome back 😅

Finally pubnix is alive! That’s im missing? Im only reading twtxt.net timeline because twtxt-v2.sh works slowly for displaying timeline…

All of physics explained in 14 minutes https://www.youtube.com/watch?v=ZAqIoDhornk

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

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

Syncthing is also as good as everyone says it is.

@movq@www.uninformativ.de 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@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? 😅

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

#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@lyse.isobeef.org How violent is the thunderstorm? 🤔

@aelaraji@aelaraji.com LOl 😂

A new thing LLM(s) can’t do well. Write patches 🤣

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

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

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

@lyse@lyse.isobeef.org Yes I think so.

Don’t forget about the upcoming Yarn.social meetup coming up this Saturday! See #jjbnvgq for details! Hope to see some/all of y’all there 💪

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

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

In fact @falsifian@www.falsifian.org you had quite a lot of good feedback, do you mind collecting them in a task list on the doc somewhere so I can get to em? 🤔