@falsifian@www.falsifian.org You will actually find that they work perfectly fine. They just tend to have little value I think. Most of our clients do support them, jenny,ttandyarnd...

At least you took the time to file an issue on a decentralised Git server 💪 Thank you! 🙏

@movq@www.uninformativ.de (#3xpygsq) @movq@www.uninformativ.de I have a slightly different but compatible view:

What makes twtxt unique is its radical technical simplicity. And that means you have to be a tech-savvy person to appreciate twtxt and that means mass-appeal is pretty much out of the question to begin with. 😅

You see, if you recall my old man ain’t all that great with tech these days, though he used to be and that’s how I got into it, encouraged as a young lad. Anyway… I built yarnd for that purpose, so a) I could use it as my daily driver (think of it like Jenny/tt but for the web with a little server) and b) so others could use it too (admitedly that hasn’t been well adopted because reasons)

Anyway my view is that Yarn/Twtxt is designed to be a slow social media without distraction. I like that a lot. Forget the simplicity for a second, if you think about how we use this, and how damn well fucking effective it is, without all the ads, tracking, god knows what useless-ass features, all the nonsense multi-Megabytes your browser has to download, just to post what you ate for breakfast, I like what we’ve built 😅

@aelaraji@aelaraji.com If you’re talking about me, I’m notorious for typos 🤣 I type too fast, and I think I need a new keyboard, these keys are getting stuck 😅 Either that or I need to take my blowvac to it and clean the dust, skin and muck under the butterfly keys 🎹

@aelaraji@aelaraji.com I just added support for passing a custom template file via -T/--template in case you need a custom template 👌

prologic@JamessMacStudio
Wed Sep 18 01:27:29
~/Projects/yarnsocial/twtxt2html
 (main) 130
$ ./twtxt2html --help
Usage: twtxt2html [options] FILE|URL

twtxt2html converts a twtxt feed to a static HTML page
  -d, --debug             enable debug logging
  -l, --limit int         limit number ot twts (default all) (default -1)
  -n, --noreldate         do now show twt relative dates
  -r, --reverse           reverse the order of twts (oldest first)
  -T, --template string   path to template file
  -t, --title string      title of generated page (default "Twtxt Feed")
  -v, --version           display version information
pflag: help requested

@movq@www.uninformativ.de Oh! 🤣 For some reason I thought my first feed was lost and gone 🤣 Hahahaha it’s been there the whole time 😅 Fuck we write good specs and software 🥳

@falsifian@www.falsifian.org I like this idea too as a completing solution to the “identify problem”:

Or maybe url changes could somehow be combined with the archive feeds extension? Could the url metadata field be local to each archive file, so that to switch to a new url all you need to do is archive everything you’ve got and start a new file at the new url?

👌

One thing that’s on my mind over the last few days about all this Twt editing and identity stuff we’ve been having hot debates over is this…

I don’t really have a problem with editing twts, or someone changing their feed’s URL.

Personally I think the folks that do are rightfully pedantic and like a good user experience, which I don’t blame ‘em. I would expect the same too. Anyway, just wanted to get that out there, I believe we can support editing and identity in a way that is still simple, as long as we bring clients along for the ride with us. The old/legacy original client though will have to remain well, ya know 😅

@movq@www.uninformativ.de Well at this point I think I’m going to try to combine @lyse@lyse.isobeef.org’s idea for supporting moving your feed to a different URL and this idea for supporting editing. I’ll spec it up and see if what we think from there…

@aelaraji@aelaraji.com Btw, I’m also open to ideas for this tool and welcome any contributions 👌

It would mean clients that support the TwtSubject and TwtHash extension, should also indicate the previous version of their Twt when editing.

Ultimately I think we just need to agree on a way to represent an edit and the previous version of a Twt in a way that makes sense. I like one of the ideas presented earlier in some other thread (god only knows which one haha 😝); That is: <timestamp> (#hash;#originalHash) <content> For example.

@movq@www.uninformativ.de I think if Git can solve the same problem of branching, forking, patching and merging, so can we 🤣

@movq@www.uninformativ.de No that’s okay. I happen to agree with you really, I just wanted to get a bit of a vibe on using cryptography in general and the idea of signing feeds. It’s not particularly about a problem being solved, just gauging your opinions/thoughts on this 👌

@aelaraji@aelaraji.com We just have to write better clients 🤣 I have figured out how to detect edits FWIW, but haven’t gone from R&D phase to an actual design and implementation. But it is possible to detect an edit as well as a similarity score and the matching Twts.

@quark@ferengi.one I think I may have lost my original feed because it was written with the old software before Yarn social became a thing.

@sorenpeter@darch.dk not really you’re really forming a cryptographic chain of twts, that are cryptographically provable by anyone, at least in one direction ). It’s called content addressing. Your propose scheme while simple doesn’t do this.

@lyse@lyse.isobeef.org and @movq@www.uninformativ.de and possibly @aelaraji@aelaraji.com and even @cuaxolotl – I’m very curious to understand and hear thoughts, pros and cons or other feelings about introducing the notation of a feed’s identify using cryptography? If we were to keep things simple, and use what’s commonly available, for example SSH ED25519 keys? using the ssh-keygen -Y sign or ssh-keygen -Y verify tools already available? Maybe in combination with @xuu ’s idea of generating a random unique ID for your feed, say # id = and signing it with your ED25519 key? 🔑

@falsifian@www.falsifian.org You mean the idea of being able to inline # url = changes in your feed?

Whatever gets used, it would be nice to be able to rotate identities. I like @lyse@lyse.isobeef.org’s idea for that.

This scheme also only support threading off a specific Twt of someone’s feed. What if you’re not replying to anyone in particular?

Noting that this scheme cannot support disjoint threads that should be merged together once either party discovers each other 😅

@movq@www.uninformativ.de It does now as of several weeks ago or so 👌

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

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

@quark@ferengi.one Haha okay 😅

@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 LOL 😂

@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 🤦‍♂️

@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 🤦‍♂️