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?
@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. š
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.
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.
@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)
@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>
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 š]
@prologic@twtxt.net Care to explain how that proves anything when someone else already got the spoofed twt with no way to tell it was? canāt an old twt just be deleted and give a similar result when grep-ed for?
Le me is worried! š
@bender@twtxt.net Just desktop notifications at the moment, but you could easily throw in a Ntfy server and get notified about anything you want, wherever you want. š¤£
š Reminder folks of the upcoming Yarn.social monthly online meetup:
I hope to see @david@collantes.us @movq@www.uninformativ.de @lyse@lyse.isobeef.org @xuu@txt.sour.is @sorenpeter@darch.dk and hopefully others too @aelaraji@aelaraji.com @falsifian@www.falsifian.org and anyone else that sees this! š Weāre hopefully going to primarily discuss the future of Twtxt and the last few weeks of discussions š¤£
- Event: Yarn.social Online Meetup
- When: 28th September 2024 at 12:00pm UTC (midday)
- Where: Mills Meet : Yarn.social
- Cadence: 4th Saturday of every Month
Agenda:
- Letās talk about the upcoming changes to the Twtxt spec(s)
- See #xgghhnq
- See #xgghhnq
(replyto:ā¦)
. Itās easier to implement and the whole edits-breaking-threads thing resolves itself in a ānaturalā way without the need to add stuff to the protocol.
@movq@www.uninformativ.de I cases of these kind of āabuseā of social trust. Then I think people should just delete their replies, unfollow the troll and leave them to shouting in the void. This is a inter-social issue, not a technical issue. Anything can be spoofed. We are not building a banking app, we are just having conversation and if trust are broken then communication breaks down. These edge-cases are all very hypothetical and not something I think we need to solve with technology.
@prologic@twtxt.net šµš» Hint: it was a twt about stolen propertyā¦
yarnd
has a couple of settings with some sensible/sane defaults:
@prologic@twtxt.net āEven though there are some š that have different views on this š¤£ā ā coyly raises the hand⦠LOL.
@aelaraji@aelaraji.com This is one of the reasons why yarnd
has a couple of settings with some sensible/sane defaults:
I could already imagine a couple of extreme cases where, somewhere, in this peaceful world oneās exercise of freedom of speech could get them in Real trouble (if not danger) if found out, it wouldnāt necessarily have to involve something to do with Law or legal authorities. So, If someone asks, and maybe fearing fearing for⦠letās just say āTheir well beingā, would it heart if a pod just purged their content if itās serving it publicly (maybe relay the info to other pods) and call it a day? It doesnāt have to be about some law/convention somewhere ⦠𤷠I know! Too extreme, but Iāve seen news of people whoād gone to jail or got their lives ruined for as little as a silly joke. And it doesnāt even have to be about any of this.
There are two settings:
$ ./yarnd --help 2>&1 | grep max-cache
--max-cache-fetchers int set maximum numnber of fetchers to use for feed cache updates (default 10)
-I, --max-cache-items int maximum cache items (per feed source) of cached twts in memory (default 150)
-C, --max-cache-ttl duration maximum cache ttl (time-to-live) of cached twts in memory (default 336h0m0s)
So yarnd
pods by default are designed to only keep Twts around publicly visible on either the anonymous Frontpage or Discover View or your Timeline or the feedās Timeline for up to 2 weeks with a maximum of 150 items, whichever get exceeded first. Any Twts over this are considered āoldā and drop off the active cache.
Itās a feature that my old man @off_grid_living@twtxt.net was very strongly in support of, as was I back in the day of yarnd
ās design (nothing particularly to do with Twtxt per se) that Iāve to this day stuck by ā Even though there are some š that have different views on this š¤£
@movq@www.uninformativ.de @falsifian@www.falsifian.org @prologic@twtxt.net Maybe I donāt know what Iām talking about and Youāve probably already read this: Everything you need to know about the āRight to be forgottenā coming straight out of the EUās GDPR Website itself. It outlines the specific circumstances under which the right to be forgotten applies as well as reasons that trump the oneās right to erasure ā¦etc.
Iām no lawyer, but my uneducated guess would be that:
A) twts are already publicly available/public knowledge and such⦠just donāt process childrenās personal data and MAYBE youāre good? Since thereās this:
⦠an organizationās right to process someoneās data might override their right to be forgotten. Here are the reasons cited in the GDPR that trump the right to erasure:
- The data is being used to exercise the right of freedom of expression and information.
- The data is being used to perform a task that is being carried out in the public interest or when exercising an organizationās official authority.
- The data represents important information that serves the public interest, scientific research, historical research, or statistical purposes and where erasure of the data would likely to impair or halt progress towards the achievement that was the goal of the processing.
B) What I love about the TWTXT sphere is itās Human/Humane element! No deceptive algorithms, no Corpo B.S ā¦etc. Just Humans. So maybe ⦠If we thought about it in this way, it wouldnāt heart to be even nicer to others/offering strangers an even safer space.
I could already imagine a couple of extreme cases where, somewhere, in this peaceful world oneās exercise of freedom of speech could get them in Real trouble (if not danger) if found out, it wouldnāt necessarily have to involve something to do with Law or legal authorities. So, If someone asks, and maybe fearing fearing for⦠letās just say āTheir well beingā, would it heart if a pod just purged their content if itās serving it publicly (maybe relay the info to other pods) and call it a day? It doesnāt have to be about some law/convention somewhere ⦠𤷠I know! Too extreme, but Iāve seen news of people whoād gone to jail or got their lives ruined for as little as a silly joke. And it doesnāt even have to be about any of this.
P.S: Maybe make X
tool check out robots.txt? Or maybe make long-term archives Opt-in? Opt-out?
P.P.S: Already Way too many MAYBEās in a single twt! So Iāll just shut up. š
Bahahahaha very clever @lyse@lyse.isobeef.org I look forward to reading your report ! 𤣠Howeverā¦
$ yarnc debug https://twtxt.net/user/prologic/twtxt.txt | grep -E '^pqst4ea' | tee | wc -l
0
I very quickly proved that Twt was never from me š¤£
@prologic@twtxt.net I have no specifics, only hopes. (I have seen some articles explaining the GDPR doesnāt apply to a āpurely personal or household activityā but I donāt really know what that means.)
I donāt know if itās worth giving much thought to the issue unless either you expect to get big enough for the GDPR to matter a lot (I imagine making money is a prerequisite) or someone specifically brings it up. Unless you enjoy thinking through this sort of thing, of course.
@falsifian@www.falsifian.org Do you have specifics about the GRPD law about this?
Would the GDPR would apply to a one-person client like jenny? I seriously hope not. If someone asks me to delete an email they sent me, I donāt think I have to honour that request, no matter how European they are.
Iām not sure myself now. So letās find out whether parts of the GDPR actually apply to a truly decentralised system? š¤
@lyse@lyse.isobeef.org yeah, tell us, @prologic@twtxt.net, what isnāt true? š¤ You canāt just go around, āthatās not true, and thatās not true; and that, and that!ā without spelling out exactly what isnāt, and why? For the love of god, why?! š
@falsifian@www.falsifian.org comments on the feeds as in nick
, url
, follow
, that kind of thing? If that, then not interested at all. I envision an archive that would allow searching, and potentially browsing threads on a nice, neat interface. You will have to think, though, on other things. Like, what to do with images? Yarn allows users to upload images, but also embed it in twtxts from other sources (hotlinking, actually).
@david@collantes.us Thanks, thatās good feedback to have. I wonder to what extent this already exists in registry servers and yarn pods. I havenāt really tried digging into the past in either one.
How interested would you be in changes in metadata and other comments in the feeds? Iām thinking of just permanently saving every version of each twtxt file that gets pulled, not just the twts. It wouldnāt be hard to do (though presenting the information in a sensible way is another matter). Compression should make storage a non-issue unless someone does something weird with their feed like shuffle the comments around every time I fetch it.
@falsifian@www.falsifian.org āI was actually thinking about making an Internet Archive style twtxt archiver, letting you explore past twtsā ā thatās an awesome idea for a project. Something I would certainly use!
(replyto:ā¦)
over (edit:#)
: (replyto:ā¦)
relies on clients always processing the entire feed ā otherwise they wouldnāt even notice when a twt gets updated. a) This is more expensive, b) you cannot edit twts once they get rotated into an archived feed, because there is nothing signalling clients that they have to re-fetch that archived feed.
@movq@www.uninformativ.de I donāt think it has to be like that. Just make sure the new version of the twt is always appended to your current feed, and have some convention for indicating itās an edit and which twt it supersedes. Keep the original twt as-is (or delete it if you donāt want new followers to see it); doesnāt matter if itās archived because you arenāt changing that copy.
@prologic@twtxt.net Do you have a link to some past discussion?
Would the GDPR would apply to a one-person client like jenny? I seriously hope not. If someone asks me to delete an email they sent me, I donāt think I have to honour that request, no matter how European they are.
I am really bothered by the idea that someone could force me to delete my private, personal record of my interactions with them. Would I have to delete my journal entries about them too if they asked?
Maybe a public-facing client like yarnd needs to consider this, but that also bothers me. I was actually thinking about making an Internet Archive style twtxt archiver, letting you explore past twts, including long-dead feeds, see edit histories, deleted twts, etc.
@prologic@twtxt.net what time in UTC?