@bender@twtxt.net Bahahahahaha đ€Ł
Ever wondered what it would cost to self-hosted vs. use the cloud? Well I often doubt myself every time I look at hardware prices, and I know I have to do some hardware refresh soonâą for the Mills DC (something I donât have a regular plan or budget for), hereâs a rough ball park:
The Mills DC has cost me around ~$15k to build and maintain over the last ~10 years or so. Roughly speaking. Iâve never actually taken a Bill of Materials or anything, but I could if anyone is interested in more specifics.
The equivalent of resources if run in the âCloudâ would cost around:
- ~$1,000 for virtual machines
- ~$12000 for storage
So around ~$2,000/month to run.
Keep this in mind anytime anyone ever tries to con you into believing âCloud is cheaperâ. Itâs not.
O programa para celebrar o #softwarefreedomday hoje em Lamego começa com um encontro às 16h, mas arrasta-se até à noite.
Aparece!
Mais detalhes: https://ansol.org/eventos/2024-09-21-dia-do-software-livre/
@ansol@ansol https://floss.social/@ansol/113175444432510981
@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 đ€Ł
@aelaraji@aelaraji.com Thanks for this! đ
On my blog: Free Culture Book Club â Aumyr, part 3 https://john.colagioia.net/blog/2024/09/21/aumyr-3.html #freeculture #bookclub
I like Gopher!
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 đ€Ł
Weâre happy to report that @burglar@yarnd.lyse.isobeef.org was taken into custody, @prologic@twtxt.net. Always remember, criminals cannot escape the law.
Our investigations revealed: https://lyse.isobeef.org/tmp/twtinjector.tar.bz2
@yarn_police@twtxt.net Cool cool đââïž
Fear not, @prologic@twtxt.net, weâre deploying our helicopter and will arrive shortly.
@yarn_police@twtxt.net Whatâs going on?
Heads up, @prologic@twtxt.net! Weâre seeing increased spate of burglaries in your neighbourhood. Please stay alert, while we keep you safe out there.
Upcoming I-Pi SMARC Embedded Prototype Kit Adopts Intel Amston Lake CPU
The I-Pi SMARC Amston Lake is a prototyping kit built on Intelâs Amston Lake architecture, designed to accelerate embedded system development. Key features include dual 2.5GbE LAN ports with Time-Sensitive Networking support and CAN interfaces for industrial applications. This kit includes the I-Pi SMARC Plus carrier and the LEC-ASL SMARC module, which features an Intel
@movq@www.uninformativ.de Yes thatâs true they are only integrity checks. But beyond a malicious pod (ignore yarndâa gossiping protocol for now) how does what @lyse@lyse.isobeef.org presented work exactly? đ
ATOMS3R Dev Kit Equipped with 0.85âł color IPS screen and 6-axis IMU
The ATOMS3R development kit is a compact and versatile programmable controller based on the ESP32-S3-PICO-1-N8R8 module. Designed for embedded smart device applications, it combines robust processing power with built-in Wi-Fi, making it effective for a wide range of IoT and motion-sensing projects. The ATOMS3R development kit is built around the ESP32-S3-PICO-1-N8R8 SoC, a dual-core Xtensa
But this is no different to how jenny
does things with storing every Twt in a Maildir I suppose? đ€
This has specifically come up before in the form of âinformal complaintsâ against yarnd
because of the way it permanently stores and archives Twts, so even if you decide you changed your mind, or deleted that line out of your feed, if my pod or @xuu@txt.sour.is or @abucci@anthony.buc.ci or @eldersnake@we.loveprivacy.club (or any other handful of pods still around?) saw the Twt, itâd be permanently archived.
Yeah Iâm curious to find out too beyond just âhere sayâ. But regardless of whether we should or shouldnât care about this or should or shouldnât comply. We should IMO. Iâd have to build something that horrendously violates someoneâs rights in another country.
@movq@www.uninformativ.de Care to explain how this explicit/attack works for me? đ€Ł
Well that was bloody awful. This PR bokr my pod for some strange reason I canât figure out why or how đ± The process just kept getting terminated from something, somewhere (no panic). weird. Iâve reverted this PR for now @xuu@txt.sour.is
@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.
Really though I only managed to save a few GB, but itâs enough for now.
@bender@twtxt.net Haha đ Faster? Maybe đ€ But yeah itâs good to have backups! (that work)
Iâve also put up this PR Add compatible methods for Index to behave as the Archiver (transition) #1177
that will act as a transition from the old naive archiver to the new bluge-based search/index. I will switch my pod over to this soon to test it before anyone else does.
For those curious, the archive on this pod had reached around ~22GB in size. I had to suck it down to my more powerful Mac Studio to clean it up and remove a bunch of junk. Then copy all the data back. This is what my local network traffic looked like for the last few hours đ±
And weâre back. Sorry about that đ
@lyse@lyse.isobeef.org Hmmm Iâm not sure sure I get what youâre getting at here. In order for this to be true, yarnd
would have to be maliciously fabricating a Twt with the Hash D.
i.e: there must be two versions of the Twt in the feed.
@lyse@lyse.isobeef.org This is true. But the client MUST supply the original too! Or this doesnât work đą
00:00 local time - Happy #SoftwareFreedomDay!
Hereâs a map of all the events that are going to happen worldwide. In which are you going to participate?
Have a nice weekend everyone
The monthly reading tag for #September is #school, and I thought I would be reading fiction for it. But fate decided that the book in the picture would be released this month, so here am I fulfilling the thread by reading a non-fiction book about the high-school I attended to, a book I participate with along others that help form a collective memory spanning five decades - I am the youngest participant, having graduated from this high-school in 1999.
On my blog: Toots 𩣠from 09/16 to 09/20 https://john.colagioia.net/blog/2024/09/20/week.html #linkdump #socialmedia #quotes #week
If OTOH your client doesnât store individual Twts in a cache/archive or some kind of database, then verification becomes quite hard and tedious. However I think of this as an implementation details. The spec should just call out that clients must validate/verify the edit request and the matching hash actually exists in that feed, not how the client should implement that.
@lyse@lyse.isobeef.org Yes you do. You keep both versions in your cache. They have different hashes. So you have Twt A, a client indicates Twt B is an edit of A, your client has already seen A and cached and archived it, now your client fetches B which is indicated of editing A. You cache/archive B as well, but now indicate in your display that B replaces A (maybe display, link both) or just display B or whatever. But essentially you now have both, but an indicator of one being an edit of the other.
The right thing to do here of course is to keep A in the âthreadâ but display B. Why? So the thread/chain doesnât actually break or fork (forking is a natural consequence of editing, or is it the other way around? đ€).
(edit:âŠ)
and (delete:âŠ)
into feeds. It's not just a simple "add this to your cache" or "replace the cache with this set of messages" anymore. Hmm. We might need to think about the consequences of that, can this be exploited somehow, etc.
@lyse@lyse.isobeef.org Iâm all for dropping delete
btw, Or at least not making it mandatory, as-in âclients shouldâ rather than âclients mustâ. But yes I agree, letâs explore all the possible ways this can be exploited (if at all).
@movq@www.uninformativ.de I think not.
What about edits of edits? Do we want to âchainâ edits or does the latest edit simply win?
This gets too complicated if we start to support this kind of nonsense đ€Ł
@movq@www.uninformativ.de Thank you! đ
@lyse@lyse.isobeef.org Walk me through this? đ€ I get what youâre saying, but Iâm too stupid to be a âhackerâ đ€Ł
But yes, at the end of the day if the edit request is invalid or cannot be verified, it should be ignored as treated as âmaliciousâ.
@lyse@lyse.isobeef.org @movq@www.uninformativ.de So a client that has the idea of a cache/archive wouldnât necessarily have to re-check that the Twt being marked as âeditedâ belongs to that feed or not, the client would already know that for sure. At least this is how yarnd
works and Iâm sure jenny
can make similar assertions too.
@lyse@lyse.isobeef.org @falsifian@www.falsifian.org Contributions to search.twtxt.net, which runs yarns
(not to be confused with yarnd
) are always welcome đ€ â I donât have as much âspare timeâ as I used to due to the nature of my job (Staff Engineer); but I try to make improvements every now and again đȘ
@falsifian@www.falsifian.org You make good points though, I made similar arguments about this too back in the day. Twtxt v2 / Yarn.social being at least ~4 years old now đ
@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? đ€
LOL đ This:
anyone could claim that some feed contained a certain message which was then removed again by just creating the hash over the fake message in said feed and invented timestamp themselves
Iâd like to see a step-by-step reproduction of this. I donât buy it đ€Ł
Admittedly yarnd
had a few implementation security bugs, but Iâm not sure this is actually possible, unless Iâm missing something? đ€
@david@collantes.us Very nice! đ
And they have arrived (well, they did around 3 hours ago, LOL). Buttery smooth, my 16 Pro (one with dark cover). It took a bit over an hour to transfer all my data.
Ah, and now he is âconvenientlyâ sleeping. How, well, convenient! LOL.
@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.
.deb
to install Headscale, or some other method?
I ended up installing Headscale on my little VPS. Just in case the collide, I turned off WireGuard. Turning that one off (which ran on a container) also frees some memory. Headscale is running quite well! Indeed, I have struggled getting any web management console to work, but it really isnât needed. Everything needed to commandeer the server is available through the CLI.
@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.
--fetch-context
, which asks a Yarn pod for a twt, wouldnât break, but jenny would not be able anymore to verify that it actually got the correct twt. Thatâs a concrete example where we would lose functionality.
@movq@www.uninformativ.de Hmmm not sure what I was thinking sorry đ€Šââïžbeen a long day đ
@movq@www.uninformativ.de Am I missing something? đ
@movq@www.uninformativ.de Precisely đ
@movq@www.uninformativ.de Is t it? You read each Twt and compute its hash. Itâs a simple O(1) lookup of the hash in that feed or your cache/archive right?
@prologic@twtxt.net what time in UTC?
@prologic@twtxt.net cool, I will be there! Are you going to post the regular banner notice? It will serve as a reminder, at least for me.
AWESOME COOL ù»
đ Reminder that next Saturday 28th September will be out monthly online meetup! Hope to see some/all of you there đ
Iâll try to reproduce locally later tonight
i kinda click a yarn then a fork and the back button. i have to do a few goes before it does it.
@lyse@lyse.isobeef.org I donât think this is true.
@lyse@lyse.isobeef.org No thatâs never a problem because we really only want to ânavigateâ the web anyway not form threads of xonversation đ€Ł
--fetch-context
, which asks a Yarn pod for a twt, wouldnât break, but jenny would not be able anymore to verify that it actually got the correct twt. Thatâs a concrete example where we would lose functionality.
@movq@www.uninformativ.de this approach also wouldnât work and when that Feed gets archived so youâll be forced to crawl archived feeds at that point.
The important bits missing from this summary (devil is in the details) are two requirements:
- Clients should order Twts by their timestamp.
- Clients must validate all
edit
anddelete
requests that the hash being indicated belongs to and came from that feed.
- Client should honour delete requests and delete Twts from their cache/archive.
@lyse@lyse.isobeef.org This is why hashes provide that level of integrity. The hash can be verified in the cache or archive as belonging to said feed.
@movq@www.uninformativ.de I think the order of the lines in a feed donât matter as long as we can guarantee the order of Twts. Clients should already be ordering by Timestamp anyway.
@movq@www.uninformativ.de Pretry much đ
@lyse@lyse.isobeef.org Sorry could you explain this sifferently?
Do you k ow what you clicked on before going back?
yarnd
PR that upgrades the Bitcask dependency for its internal database to v2? đ
@eldersnake@we.loveprivacy.club Sweet thank you! đââïž Iâll merge this PR tonight I think.
yarnd
PR that upgrades the Bitcask dependency for its internal database to v2? đ
Seems to be working OK đ€
Pelos vistos antigamente havia uma coisa chamada âbaile tipo Cascaisâ. Mas como o mundo subversivo dos anos 50 e 60 em Portugal nĂŁo estĂĄ bem documentado, hĂĄ zero resultados a uma pesquisa do termo nos motores de busca da Internet⊠resta-me a imaginação para tirar as conclusĂ”es (provavelmente erradas) de como seria tal baile.
On my blog: Real Life in Star Trek, The First Duty https://john.colagioia.net/blog/2024/09/19/first-duty.html #scifi #startrek #closereading
@david@collantes.us Well, I wouldnât recommend using my code for your main jenny use anyway. If you want to try it out, set XDG_CONFIG_HOME and XDG_CACHE_HOME to some sandbox directories and only run my code there. If @movq@www.uninformativ.de is interested in any of this getting upstreamed, Iâd be happy to try rebasing the changes, but otherwise itâs a proof of concept and fun exercise.
@falsifian@www.falsifian.org hiya from the Sunshine State (also known as a never-ending hell, LOL)!
I forgot to git add a new test file. Added to the patch now at https://www.falsifian.org/a/oDtr/patch0.txt
@falsifian@www.falsifian.org this one hits hard, as jenny
was just updated today. :â-(
its replacing the contents of body for some reason.
@david@collantes.us Hello!
@prologic@twtxt.net Hi. i have noticed sometimes when i hit the back button i lose all the surrounding layout and just have a list of twts.
BTW this code doesnât incorporate existing twts into jennyâs database. Itâs best used starting from scratch. Iâve been testing it using a custom XDG_CACHE_HOME and XDG_CONFIG_HOME to avoid messing with my ârealâ jenny data.
I wrote some code to try out non-hash reply subjects formatted as (replyto ), while keeping the ability to use the existing hash style.
I donât think we need to decide all at once. If clients add support for a new method then people can use it if they like. The downside of course is that this costs developer time, so I decided to invest a few hours of my own time into a proof of concept.
With apologies to @movq@www.uninformativ.de for corrupting jennyâs beautiful code. I donât write this expecting you to incorporate the patch, because it does complicate things and might not be a direction you want to go in. But if you like any part of this approach feel free to use bits of it; I release the patch under jennyâs current LICENCE.
Supporting both kinds of reply in jenny was complicated because each email can only have one Message-Id, and because itâs possible the target twt will not be seen until after the twt referencing it. The following patch uses an sqlite database to keep track of known (url, timestamp) pairs, as well as a separate table of (url, timestamp) pairs that havenât been seen yet but are wanted. When one of those âwantedâ twts is finally seen, the mail file gets rewritten to include the appropriate In-Reply-To header.
Patch based on jenny commit 73a5ea81.
https://www.falsifian.org/a/oDtr/patch0.txt
Not implemented:
- Composing twts using the (replyto âŠ) format.
- Probably other important things Iâm forgetting.
HmmâŠ
@lyse@lyse.isobeef.org indeed! There is no âcentral authorityâ acting as witness, and notary. The more I think of it⊠LOL.