↳ In-reply-to » I finally decided to do a few experiments with yarnd to see how many things would break and how many assumptions there are around the idea of "Content Addressing"; here's where I'm at so far:

@prologic@twtxt.net

This scope of changes is much easier to implement for yarnd and I suspect jenny too.

No, (edit:) is a lot of work for jenny and also adds a lot of overhead.

Right now, jenny itself has no idea which twt hashes are present on which feed, because it doesn’t need to. This information only exists in the mail files. This means I can’t check if an (edit:) operation is legal. jenny will have to get an sqlite database (or read/parse/write 1-2 MB of JSON on every invocation, which isn’t great either).

I’ve already spent several hours this morning rewriting the feed fetching/parsing code in an effort to pave the way to even be able to support any of this. I’ll spare you the details. Until now, twts were individual items in a feed, they could be processed in any order and they didn’t reference each other from jennys point of view. A lot of the heavy lifting happens in the mail client.

Honestly, the database thing bugs me the most. The whole concept of “just create some mail files” doesn’t really work anymore. I now have to duplicate state between the mail files and an internal database. This is a big “meh”.

Of course, if we were to switch to location-based addressing, then you would have to do a lot of work. There’s no easy way out.

Maybe I could say jenny does not support (edit:) for now. That’s the good thing about this proposal: I don’t have to implement it right away. Users will see spurious twts (or I could hide them as a workaround) and they won’t see twt updates, but nothing will break.