@prologic@twtxt.net, are you running Gitea with an SQL backend, or using sqlite? Any reason have havenāt moved to Forgejo?
@prologic@twtxt.net a wise plan! Who knows, ideas change, and often plans do not hash, right? Mature, mature! :-)
@xuu@txt.sour.is was that 2% picked out randomly? I like it! LOL.
@prologic@twtxt.net I like the, allegedly, original:
āIt can scarcely be denied that the supreme goal of all theory is to make the irreducible basic elements as simple and as few as possible without having to surrender the adequate representation of a single datum of experience.ā
Not as simple as the interpretation you used, yet often context is king (or queen).
@prologic@twtxt.net and one could say that āfor every simple problem, there is a solution thatās confusing, convoluted, and right.ā :-P
@prologic@twtxt.net so, where are they? I want to take a peek at HomeTunnel (even though I donāt a use case for it at the moment). Show us repos! :-P
@david@collantes.us yeah what @lyse@lyse.isobeef.org said. š and I just chickened out seeing bigger numbers than usual.
rsync(1)
but, whenever I Tab
for completion and get this:
@lyse@lyse.isobeef.org and @movq@www.uninformativ.de thanks for sharing those options, theyāre a good point to start from. Much appreciated! š
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!
@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
@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?
@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.
This is only first draft quality, but I made some notes on the #twtxt v2 proposal. http://a.9srv.net/b/2024-09-25
No, json is overhead. I love twtxt for simplicity where blog is just text file and not several json files where fields are repeatedā¦
@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
(#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.
@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
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.
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.
rsync(1)
but, whenever I Tab
for completion and get this:
@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. š
(#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
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)
.
@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:
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.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.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.
Finally pubnix is alive! Thatās im missing? Im only reading twtxt.net timeline because twtxt-v2.sh works slowly for displaying timelineā¦
rsync(1)
but, whenever I Tab
for completion and get this:
@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.
@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.
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
@xuu@txt.sour.is I think it is more tricky than that.
āA company or entity ā¦ā
Also, as I understand it, āpersonal or household activityā (as you called it) is rather strict: An example could be you uploading photos to a webspace behind HTTP basic auth and sending that link to a friend. So, yes, a webserver is involved and you process your friendās data (e.g., when did he access your files), but itās just between you and him. But if you were to publish these photos publicly on a webserver that anyone can access, then itās a different story ā even though you could say that āthis is just my personal hobby, not related to any job or moneyā.
If you operate a public Yarn pod and if you accept registrations from other users, then Iām pretty sure the GDPR applies. š¤ You process personal data and you donāt really know these people. Itās not a personal/private thing anymore.
@falsifian@www.falsifian.org I believe the preserve means to include the original subject hash in the start of the twt such as (#somehash)
So I whipped up a quick shell script to demonstrate what I mean by the increase in feed size on average as well as the expected increase in storage and retrieval requirements.
$ ./compare.sh
Original file size: 28145 bytes
Modified file size: 70672 bytes
Percentage increase in file size: 151.10%
...
@bender@twtxt.net Ha! Maybe I should get on the Markdown train. Youāre taking away my excuses.
Sorry, youāre right, I should have used numbers!
Iām donāt understand what āpreserve the original hashā could mean other than āmake sure thereās still a twt in the feed with that hashā. Maybe the text could be clarified somehow.
Iām also not sure what you mean by markdown already being part of it. Of course people can already use Markdown, just like presumably nothing stopped people from using (twt subjects) before they were formally described. But itās not universal; e.g. as a jenny user I just see the plain text.
@falsifian@www.falsifian.org The GDPR does not apply to the processing of data for a purely personal or household activity that is not connected to a professional or commercial activity.
@prologic@twtxt.net Do you feel the same about published vs. privately stored data?
For me thereās a distinction. I feel very strongly that I should be able to retain whatever private information I like. On the other hand, I do have some sympathy for requests not to publish or propagate (though I personally feel itās still morally acceptable to ignore such requests).
@lyse@lyse.isobeef.org 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.)
@prologic@twtxt.net Thanks for writing that up!
I hope it can remain a living document (or sequence of draft revisions) for a good long time while we figure out how this stuff works in practice.
I am not sure how I feel about all this being done at once, vs. letting conventions arise.
For example, even today I could reply to twt abc1234 with ā(#abc1234) Edit: ā¦ā and I think all you humans would understand it as an edit to (#abc1234). Maybe eventually it would become a common enough convention that clients would start to support it explicitly.
Similarly we could just start using 11-digit hashes. We should iron out whether itās sha256 or whatever but thereās no need get all the other stuff right at the same time.
I have similar thoughts about how some users could try out location-based replies in a backward-compatible way (append the replyto: stuff after the legacy (#hash) style).
However I recognize that Iām not the one implementing this stuff, and itās less work to just have everything determined up front.
Misc comments (I havenāt read the whole thing):
Did you mean to make hashes hexadecimal? You lose 11 bits that way compared to base32. Iād suggest gaining 11 bits with base64 instead.
āClients MUST preserve the original hashā ā do you mean they MUST preserve the original twt?
Thanks for phrasing the bit about deletions so neutrally.
I donāt like the MUST in āClients MUST follow the chain of reply-to referencesā¦ā. If someone writes a client as a 40-line shell script that requires the user to piece together the threading themselves, IMO we shouldnāt declare the client non-conforming just because they didnāt get to all the bells and whistles.
Similarly I donāt like the MUST for user agents. For one thing, you might want to fetch a feed without revealing your identty. Also, it raises the bar for a minimal implementation (Iām again thinking again of the 40-line shell script).
For āwho followsā lists: why must the long, random tokens be only valid for a limited time? Do you have a scenario in mind where they could leak?
Why canāt feeds be served over HTTP/1.0? Again, thinking about simple software. I recently tried implementing HTTP/1.1 and it wasnāt too bad, but 1.0 would have been slightly simpler.
Why get into the nitty-gritty about caching headers? This seems like generic advice for HTTP servers and clients.
Iām a little sad about other protocols being not recommended.
I donāt know how I feel about including markdown. I donāt mind too much that yarn users emit twts full of markdown, but Iām more of a plain text kind of person. Also it adds to the length. I wonder if putting a separate document would make more sense; that would also help with the length.
So Iām a location based system, how exactly do I reply to one of these two Twts from @Yarns@search.twtxt.net ? š¤
2024-09-07T12:55:56Z š„³ NEW FEED: @<twtxt http://edsu.github.io/twtxt/twtxt.txt>
2024-09-07T12:55:56Z š„³ NEW FEED: @<kdy https://twtxt.kdy.ch/twtxt.txt>
Okay folks, Iāve spent all day on this today, and I think its in āgood enoughā⢠shape to share:
Twtxt v2:
- Specification: https://docs.mills.io/uJXuisaYTRWYDrl8A2jADg?both
- implementation: https://gist.mills.io/prologic/afdec15443da4d7aa898f383f171ec1b
LOl š Not only have a tried to write up a full Twtxt v2 specification, Iāve also written a Bash shell script that implements the new spec š
Had to build a list of all feeds (that I follow) and all twts in them and there are two collisions already:
$ ./stats
Saw 58263 hashes
7fqcxaa
https://twtxt.net/user/justamoment/twtxt.txt
https://twtxt.net/user/prologic/twtxt.txt
ntnakqa
https://twtxt.net/user/prologic/twtxt.txt
https://twtxt.net/user/thecanine/twtxt.txt
Namely:
$ jenny -D https://twtxt.net/user/justamoment/twtxt.txt | grep 7fqcxaa
[7fqcxaa] [2022-12-28 04:53:30+00:00] [(#pmuqoca) @prologic@twtxt.net I checked the GitHub discussion, it became a request to join forces.
Do you plan on having them join?
Also for the name, how about:
- āprogitā or āprologitā (prologic official hard fork)
- āgit-stanceā (git instance)
- āGitTreeā (Gitea inspired, maybe to related)
- āGitomataā (git automata)
- āGit.Sourceā
- āForgorā (forgit is taken so I forgor) š¤£
- āSweetGitā (as salty chat)
- āPepper Gitā (other ingredients) š
- āGitHeartā (core of git with a GitHub sounding name)
- āGitTakaā (With music in mind)
Ok, enough fun⦠Hope this helps sprout some ideas from others if nothing is to your taste.]
$ jenny -D https://twtxt.net/user/prologic/twtxt.txt/5 | grep 7fqcxaa
[7fqcxaa] [2022-02-25 21:14:45+00:00] [(#bqq6fxq) Itās handled by blue Monday]
And:
$ jenny -D https://twtxt.net/user/thecanine/twtxt.txt | grep ntnakqa
[ntnakqa] [2022-01-23 10:24:09+00:00] [(#2wh7r4q) <a href="https://yarn.girlonthemoon.xyz/external?uri=https://twtxt.net/user/prologic/twtxt.txt">@prologic<em>@twtxt.net</em></a> I know, I was just hoping it might have also gotten fixed by that change, by some kind of backend miracles. š]
$ jenny -D https://twtxt.net/user/prologic/twtxt.txt/1 | grep ntnakqa
[ntnakqa] [2024-02-27 05:51:50+00:00] [(#otuupfq) <a href="https://yarn.girlonthemoon.xyz/external?uri=https://twtxt.net/user/shreyan/twtxt.txt">@shreyan<em>@twtxt.net</em></a> Ahh š]