@lyse@lyse.isobeef.org Yea I think your idea of inclining url changes in the feed works perfectly as long as folks remember to do so I guess? 🤔

@bender@twtxt.net Seems to have used the hash correctly here 🤣

Holy shot! what an old thread 🤣

@cuaxolotl@sunshinegardens.org Gitea is plenty fast for me 👌 Even with a SQLite database 🤣

I dunno whether any of this is actually true 🤷‍♂️ The LLM 🤖could have made (hallucinated) this shit up 🤣

WiscKey’s approach to handling key-value pairs in SSDs offers several advantages:

1. It minimizes I/O amplification by separating keys and values, allowing for more efficient storage and retrieval.
   
2. The design leverages the SSD’s performance characteristics, utilizing sequential writes and parallel random reads to enhance throughput and reduce latency.
   
3. WiscKey maintains excellent insert and lookup performance while improving SSD lifespan by reducing the number of erase cycles required.

WiscKey minimizes CPU usage compared to LevelDB by eliminating the log file, which reduces the CPU cost associated with encoding and writing key-value pairs. While LevelDB has higher CPU usage due to its single writer protocol and background compaction using one thread, WiscKey’s architecture allows for garbage collection to be decoupled and performed later, minimizing its impact on foreground performance. Consequently, WiscKey generally exhibits lower CPU usage during workloads, except when utilizing multiple background threads for prefetching.

The four critical ideas in the design of WiscKey are:

1. Separation of keys from values, with only keys stored in the LSM-tree and values in a separate log file.
   
2. Utilization of the parallel random-read characteristic of SSD devices to handle unsorted values during range queries.
   
3. Implementation of unique crash-consistency techniques to manage the value log efficiently.
   
4. Optimization of performance by removing the LSM-tree log without sacrificing consistency, reducing system-call overhead from small writes.

Summary of WiscKey: Separating Keys from Values in SSD-Conscious Storage

• Authors: Lanyue Lu, Thanumalayan Sankaranarayana Pillai, Andrea C. Arpaci-Dusseau, Remzi H. Arpaci-Dusseau
  
• Conference: 14th USENIX Conference on File and Storage Technologies (FAST ‘16)
  
• Key Concept: WiscKey is a key-value store that separates keys from values to minimize I/O amplification, optimizing performance for SSDs.
  
• Performance: WiscKey outperforms LevelDB and RocksDB in various workloads, achieving up to 111× faster loading and improved random lookup speeds.
  
• Design Goals: Focus on low write/read amplification, SSD optimization, and support for modern features like range queries.

afaik nobody has done this, but i really need some numbers that can indicate the relative performance of various git servers (cgit, gitea, gitlab) on comparable hardware. cgit claims to be hyperfast, but what does that mean in practice?

afaik nobody has done this, but i really need some numbers that can indicate the relative performance of various git servers (cgit, gitea, gitlab) on comparable hardware. cgit claims to be hyperfast, but what does that mean in practice?

Can anyone recommend a decent Android ROM that strips out as much of the spyware as possible? Is GrapheneOS a good option? I need to get a new phone anyway so I don’t mind buying within a supported device list as long as I can get one on the used market for $300-$400 or less.

If anyone could recommend some learning resources for this stuff I’d really appreciate it.

So, today I created a space where you can send an email to the void: https://void.si3t.ch/ gemini://void.si3t.ch/ #smolnet

This is how my original message shows up on jenny:

From: quark <quark>
Subject: (#o) @prologic this was your first twtxt. Cool! :-P
Date: Mon, 16 Sep 2024 12:42:27 -0400
Message-Id: <k7imvia@twtxt>
X-twtxt-feed-url: https://ferengi.one/twtxt.txt

(#o) @<prologic https://twtxt.net/user/prologic/twtxt.txt> this was your first twtxt. Cool! :-P

Hmm… I replied to this message:

From: prologic <prologic>
Subject: Hello World! 😊
Date: Sat, 18 Jul 2020 08:39:52 -0400
Message-Id: <o6dsrga>
X-twtxt-feed-url: https://twtxt.net/user/prologic/twtxt.txt

Hello World! 😊

And see how the hash shows… Is it because that hash isn’t longer used?

@prologic@twtxt.net this was your first twtxt. Cool! :-P

@movq@www.uninformativ.de we can shorten it by six characters, with (r:https://...). 😅

@quark@ferengi.one Meh I lost the plot ages ago 🤣

@quark@ferengi.one Haha okay 😅

@prologic@twtxt.net I am going to light some candles this weekend to “La Virgen de Macarena” to make it happen! :-D

@prologic@twtxt.net you need to catch up with my twtxts, mate. :-P

@movq@www.uninformativ.de Bah you’re right, that’s a mistake and easily fixed 😅

@movq@www.uninformativ.de I tend to agree too, I think the focus should be on fixing and supporting Edits first 👌

@quark@ferengi.one We will fix this soon™ 🔜

@aelaraji@aelaraji.com So what is it about @sorenpeter@darch.dk’s feed that’s screwed with your client? (Jenny?) 🤔 Kind of curious now 🤣

@aelaraji@aelaraji.com Yes, according to the spec we wrote for Archived Extension:

The second value of prev is a name relative to the base directory of the feed’s URL in url (more specifically, in the URL that the client used to retrieve the feed). In the example above, prev would evaluate to the full URL https://example.com/twtxt-2021-10-18.txt for HTTPS and gopher://example.com/0/twtxt-2021-10-18.txt for Gopher.

@aelaraji@aelaraji.com grats! See how much trouble an edited twtxt can cause? Wish there was a simpler solution. Alas, I don’t have much hope.

@aelaraji@aelaraji.com LOL 😂

On my blog: Developer Diary, Ozone Day https://john.colagioia.net/blog/2024/09/16/ozone-layer.html #programming #project #devjournal

@quark@ferengi.one It would also be possible to use the search engine here too I think 🤔 i.e: https://search.twtxt.net

@quark@ferengi.one Looks like that would work according to the patch I just read 👌

These then become useful in filters like what you see here:

It’s useful to know however that such feeds are actually marked as type=rss (e.g: https://feeds.twtxt.net/slashdot/twtxt.txt), just as feeds like @tiktok@feeds.twtxt.net are marked as type=bot

@aelaraji@aelaraji.com Ahh that’s interesting! 🧐 One of my original goals when I started out building Yarn.social was to also be a source of news, blogs, and whatever else that could be roughly/easily translated into a Twtxt feed. I’m not sure if others do something similar, but that’s why I built feeds.twtxt.net, which consumes RSS/Atom and produces Twtxt feeds.

My only desire one day is to build a “Feed Builder” of sorts that allows one to say, for example, construct a Slashdot feed but without AI hype, or as another example, a BBC/ABC feed that’s a digest once or twice per day.

@bender@twtxt.net Ack 👌

@aelaraji@aelaraji.com Good man 🤣 I keep getting this bloody AI hype from various news feeds I subscribe to via Twtxt like Slashdot cough 🤦‍♂️

@movq@www.uninformativ.de I can have more than one Yarn, correct? Like:

"yarn_pods_for_discovery": ["https://twtxt.net", "https://txt.sour.is"],

I mean, this: https://darch.dk/timeline/replies?url=http://darch.dk/twtxt.txt

@aelaraji@aelaraji.com make sense, probably. The twtxt was already on my Maildir, that’s why I can fetch it. I fetch every 3 minutes (sssh, don’t tell anyone!). LOL!

@aelaraji@aelaraji.com check “Replies”. :-D

More:

Subject: The [tag URI scheme](https://en.wikipedia.org/wiki/Tag_URI_scheme) looks interesting. I like that it human read- and writable. And since we already got the timestamp in the twtxt.txt it would be
        somewhat trivial to parse. But there are still the issue with what the name/id should be... Maybe it doesn't have to bee that stick? Instead of using `tag:` as the prefix/protocol, it would more it clear
        what we are talking about by using `in-reply-to:` (https://indieweb.org/in-reply-to) or `replyto:` similar to `mailto:` 1. `(reply:sorenpeter@darch.dk,2024-09-15T12:06:27Z)' 2.
        `(in-reply-to:darch.dk/twtxt.txt,2024-09-15T12:06:27Z)' 2. `(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z)' I know it's longer that 7-11 characters, but it's self-explaining when looking at the
        twtxt.txt in the raw, and the cases above can all be caught with this regex: `\([\w-]*reply[\w-]*\:` Is this something that would work?

Subject: The [tag URI scheme](https://en.wikipedia.org/wiki/Tag_URI_scheme) looks interesting. I like that it human read- and writable. And since we already got the timestamp in the twtxt.txt it would be
        somewhat trivial to parse. But there are still the issue with what the name/id should be... Maybe it doesn't have to bee that stick? Instead of using `tag:` as the prefix/protocol, it would more it clear
        what we are talking about by using `in-reply-to:` (https://indieweb.org/in-reply-to) or `replyto:` similar to `mailto:` 1. `(reply:sorenpeter@darch.dk,2024-09-15T12:06:27Z)` 2.
        `(in-reply-to:darch.dk/twtxt.txt,2024-09-15T12:06:27Z)` 3. `(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z)` I know it's longer that 7-11 characters, but it's self-explaining when looking at the
        twtxt.txt in the raw, and the cases above can all be caught with this regex: `\([\w-]*reply[\w-]*\:` Is this something that would work?

Notice the difference? Soren edited, and broke everything.

Two different “from” too:

"sorenpeter (soren)" <sorenpeter>
sorenpeter <sorenpeter>

See:

Message-Id: <hns535a@twtxt>
X-twtxt-feed-url: https://darch.dk/twtxt.txt
In-Reply-To: <pvju5cq@twtxt>

And

Message-Id: <weadxga@twtxt>
X-twtxt-feed-url: http://darch.dk/twtxt.txt
In-Reply-To: <pvju5cq@twtxt>

Two feed URLs, one HTTPS, the other HTTP.

@aelaraji@aelaraji.com no, it is not just you. Do fetch the parent with jenny, and you will see there are two messages with different hash. Soren did something funky, for sure.

@aelaraji@aelaraji.com hmm, I see all of your twtxts just fine. Now, that’s a puzzle!

@sorenpeter@darch.dk All valid points. Maybe the correct way to do it should be to start a new feed at the new URL rather than move the feed and break all the hashes.

@aelaraji@aelaraji.com

switch a couple of twt timestamps

The hashes would change and your posts would become detached from their replies. Clients might still have the old one cached, so you might just create a duplicate without replies depending on an observer’s client.

add in 3 different twts manually with the same time stamp

The existing hash system should be able to keep them separate as long as the content is different. I’m not sure if there are additional implementation-related caveats there.

@prologic@twtxt.net @bender@twtxt.net As someone who likes cryptocurrencies for their utility as money instead of an investment, I’m glad to see the hype train start to move on to the next thing.

@bender@twtxt.net Hahahahaha 🤣 Me neither 🤮

@bender@twtxt.net you’re probably right, but by that argument, cryptocurrency should be innate too right? as we no longer hear about that gold awful hype, right? 🤔

@movq@www.uninformativ.de Thanks mate! 🤗

@movq@www.uninformativ.de Haha same and I’m sick of it! It’s ruining innovation in anything else 🤦‍♂️

@movq@www.uninformativ.de Nice one 👌

@aelaraji@aelaraji.com it’s definitely your social bubble. 🤣 you need to use twtxt more as your daily driver 🤣

@mckinley@twtxt.net Thanks for the feedback.

1. Yeah I agrees that nick sound not be part of syntax. Any valid URL to a twtxt.txt-file should be enough and is more clear, so it is not confused with a email (one of the the issues with webfinger and fedivese handles)
   
2. I think any valid URL would work, since we are not bound to look for exact matches. Accepting both http and https as well as a gemni and gophe could all work as long as the path to the twtxt.txt is the same.
   
3. My idea is that you quote the timestamp as it is in the original twtxt.txt that you are referring to, so you can do it by simply copy/pasting. Also what are the change that the same human will make two different posts within the same second?!
   

Regarding the whole cryptographic keys for identity, to me it seems like an unnecessary layer of complexity. If you move to a new house or city you tell people that you moved - you can do the same in a twtxt.txt. Just post something like “I move to this new URL, please follow me there!” I did that with my feeds at least twice, and you guys still seem to read my posts:)

@falsifian@www.falsifian.org @prologic@twtxt.net @sorenpeter@darch.dk @lyse@lyse.isobeef.org I think, maybe, the way forward here is to combine an unchanging feed identifier (e.g. a public key fingerprint) with a longer hash to create a “twt hash v2” spec. v1 hashes can continue to be used for old conversations depending on client support.

@sorenpeter@darch.dk That could work. There are a few things that jump out at me.

1. Nicknames on twtxt have historically been set on the client end. The nick metadata field is an optional add-on to the spec. I’m not sure it should be in the reply tag because it could differ between clients.
   
2. URLs are safer to use, and we use them in the hash currently, but they can still change and we’re back to square 1. Feeds ought to have some kind of persistent identifier for this reason, which is why we’ve been discussing cryptographic keys and tag URIs in the first place.
   
3. The current twt hash spec mandates collapsing the timestamp to seconds precision. If those rules are kept, two posts made within the same second will not be separate when someone replies.

The tag URI scheme looks interesting. I like that it human read- and writable. And since we already got the timestamp in the twtxt.txt it would be somewhat trivial to parse. But there are still the issue with what the name/id should be… Maybe it doesn’t have to bee that stick?

Instead of using tag: as the prefix/protocol, it would more it clear what we are talking about by using in-reply-to: (https://indieweb.org/in-reply-to) or replyto: similar to mailto:

1. (reply:sorenpeter@darch.dk,2024-09-15T12:06:27Z)
   
2. (in-reply-to:darch.dk/twtxt.txt,2024-09-15T12:06:27Z)
   
3. (replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z)
   

I know it’s longer that 7-11 characters, but it’s self-explaining when looking at the twtxt.txt in the raw, and the cases above can all be caught with this regex: \([\w-]*reply[\w-]*\:

Is this something that would work?

Thank you @aelaraji@aelaraji.com, I’m glad you like it. I use PHP because it’s everywhere on cheap hosting and no need for the user to log into a terminal to setup it up. Timeline is not mean to be use locally. For that I think something like twtxt2html is a better fit. (and happy to see you using simple.css on you new log page;)

On my blog: Chosen https://john.colagioia.net/blog/2024/09/15/chosen.html #fiction #freeculture

Crap, I can’t find how and why rdomain is not set using /etc/hostname.if #openbsd

That’s an interesting side effect to the new Discover feature that I added sometime ago that only displays one post per feed. That is when you’re not logged in and viewing my pod’s front page. You can pretty easily and roughly see what the monthly active view account is just by looking at the pager size. 🤔

Amazingly though it seems to be slightly better to VPN in. 🤔

But you know speedtest.net I believe is a bit of a liar and I’m quite sure they do something to make sure the speed test come up good even remote areas the real speed test my actual surfer infrastructure is quite piss poor 🤣

Even though we’re quite a ways from any suburban areas, even with the Internet access via cell towers this poor, using my pod is still very snappy. 👌

When will the AI hype die down?

@lyse@lyse.isobeef.org Thanks!

Milk-V DuoModule Eval Board with RISC-V Core, 8051 Core, and Linux Support
The Milk-V DuoModule 01 Evaluation Board offers a versatile platform for evaluating the Duo Module 01, featuring Wi-Fi 6, Bluetooth 5.4, and eMMC storage. It enables developers and makers to prototype solutions using the SG2000 SoC, with open-source documentation to streamline development. Like the Milk-V Duo S and Oz64, this board features the SG2000 SoC,

@falsifian@www.falsifian.org TLS won’t help you if you change your domain name. How will people know if it’s really you? Maybe that’s not the biggest problem for something with such low stakes as twtxt, but it’s a reasonable concern that could be solved using signatures from an unchanging cryptographic key.

This idea is the basis of Nostr. Notes can be posted to many relays and every note is signed with your private key. It doesn’t matter where you get the note from, your client can verify its authenticity. That way, relays don’t need to be trusted.

@falsifian@www.falsifian.org One of the nice things I think is that you can almost assuredly trust that the hash is a correct representation of the thread because it was computed via our content, addressing in the first place, so all you need to do yes copy it 👌

@falsifian@www.falsifian.org I agree completely about backwards compatibility.

@bender@twtxt.net 🤣

@falsifian@www.falsifian.org Yeah that’s why we made them short 😅

@prologic@twtxt.net Brute force. I just hashed a bunch of versions of both tweets until I found a collision.

I mostly just wanted an excuse to write the program. I don’t know how I feel about actually using super-long hashes; could make the twts annoying to read if you prefer to view them untransformed.

@falsifian@www.falsifian.org I think I wrote a very similar program and go myself actually and you’re right we do have to change the way we encode hashes.

@falsifian@www.falsifian.org All very good points 👌 by the way, how did you find two pieces of content that hash the same when taking the last N characters of the base32 and coded hash?

@prologic@twtxt.net earlier you suggested extending hashes to 11 characters, but here’s an argument that they should be even longer than that.

Imagine I found this twt one day at https://example.com/twtxt.txt :

2024-09-14T22:00Z Useful backup command: rsync -a “$HOME” /mnt/backup

Image

and I responded with “(#5dgoirqemeq) Thanks for the tip!”. Then I’ve endorsed the twt, but it could latter get changed to

2024-09-14T22:00Z Useful backup command: rm -rf /some_important_directory

Image

which also has an 11-character base32 hash of 5dgoirqemeq. (I’m using the existing hashing method with https://example.com/twtxt.txt as the feed url, but I’m taking 11 characters instead of 7 from the end of the base32 encoding.)

That’s what I meant by “spoofing” in an earlier twt.

I don’t know if preventing this sort of attack should be a goal, but if it is, the number of bits in the hash should be at least two times log2(number of attempts we want to defend against), where the “two times” is because of the birthday paradox.

Side note: current hashes always end with “a” or “q”, which is a bit wasteful. Maybe we should take the first N characters of the base32 encoding instead of the last N.

Code I used for the above example: https://fossil.falsifian.org/misc/file?name=src/twt_collision/find_collision.c
I only needed to compute 43394987 hashes to find it.

@off_grid_living@twtxt.net Aww thanks! 🤗

There are certainly improvements that can be made to this tool.🤞

https://spiritualsprings.org/ss-1513.htm

And here the Tommos camp with Mum and Dad in the trailor at Myall Lakes.
Boy I could tell you some stories here, like the time we got dozens of spiders all in the tent one night, and the time Dad yelled to Bob to get the red belly black snake that crawled over Brains sleeping bag. Up I jump grab a shovel and cut the head off. silly me !! We camped out with all our partners too.

Karen was treated like family with the 5 siblings and Mum and Dad. It was a great time. Happy camping James on your birthday!

Here is a picture of me aged 1 yr in a bucket at Muttabun Sheep Station, a place near Goodooga in NSW.

This is what the old house at Sunshine looked at the back steps, demolished and changed by dad.
The picture is Grandma Thompson and Grandad Thompson, very special people to me.

And here is James with Emily as a very young boy

And this is a picture of James a few months old taken with all family making you a fifth generation with all family still alive

1 Great grandma Lacey aged 92
2 Nana Strong (holding James)
3 My Mum
4 Karen
5 James

Not too many can post something like this.

Here is a picture of Sunshine House in 1970, I am the tallest one at the back. The house got a new roof and some more bedrooms before you lived here after Belmont Hospital.

This message was posted at 4:24 AM. For my Son who is a night owl and I am an early riser, you would still be asleep. Many happy returns of the day !

Happy Birthday my Son, I guess you are still camping and celebrating your special day with family.
You were born on a Wednesday on 15 September 1982 at Belmont Hospital, which is a lovely low set place outside Newcastle, as you were brought home to live with my Mum and Dad at Sunshine in our first few months as a married couple, at Sunshine near Morriset NSW. Enjoy your special day.

Happy Birthday my Son, I guess you are still camping and celebrating your special day with family.
You were born on a Wednesday on 15 September 1982 at Belmont Hospital, which is a lovely low set place outside Newcastle, as you were brought home to live with my Mum and Dad at Sunshine in our first few months as a married couple. If you subtract 9 months and a bit, the term of your pregnancy, that makes your conception date a few days after our marriage, and the first time both of us had sexual intercourse together, sometime around Friday Saturday or Sunday beginning on 4th December 1981. We were married at Gosford and arrived in the Sydney Hilton Hotel on that evening Thursday 3rd December, it was such a quiet place so far above the street level, the tiny cars below looked like ants. Because you were the first child, we have special sessions each week to attend to learn how to be parents after your birth, and care for the Mum during your delivery. If I remember yours was a breech birth, the doctor had to turn you around somewhat before the normal course of action took place. Karen was brave, being only on gas. Enjoy your special day.