Hmmmm, I somehow run into an encoding problem where my inserted data end up mangled in the database. But, both SQLite and Go use UTF-8. What’s happening here? :-?

@bender@twtxt.net Yes, they do 🤣 Implicitly, or threading would never work at all 😅 Nor lookups 🤣 They are used as keys. Think of them like a primary key in a database or index. I totally get where you’re coming from, but there are trade-offs with using Message/Thread Ids as opposed to Content Addressing (like we do) and I believe we would just encounter other problems by doing so.

My money is on extending the Twt Subject extension to support more (optional) advanced “subjects”; i.e: indicating you edited a Twt you already published in your feed as @falsifian@www.falsifian.org indicated 👌

Then we have a secondary (bure much rarer) problem of the “identity” of a feed in the first place. Using the URL you fetch the feed from as @lyse@lyse.isobeef.org ’s client tt seems to do or using the # url = metadata field as every other client does (according to the spec) is problematic when you decide to change where you host your feed. In fact the spec says:

Users are advised to not change the first one of their urls. If they move their feed to a new URL, they should add this new URL as a new url field.

See Choosing the Feed URL – This is one of our longest debates and challenges, and I think (_I suspect along with @xuu@txt.sour.is _) that the right way to solve this is to use public/private key(s) where you actually have a public key fingerprint as your feed’s unique identity that never changes.

Correct, @bender@twtxt.net. Since the very beginning, my twtxt flow is very flawed. But it turns out to be an advantage for this sort of problem. :-) I still use the official (but patched) twtxt client by buckket to actually fetch and fill the cache. I think one of of the patches played around with the error reporting. This way, any problems with fetching or parsing feeds show up immediately. Once I think, I’ve seen enough errors, I unsubscribe.

tt is just a viewer into the cache. The read statuses are stored in a separate database file.

It also happened a few times, that I thought some feed was permanently dead and removed it from my list. But then, others mentioned it, so I resubscribed.

today i will start trying to extract my dots from my memex database and manage the dependency tree entirely using nix flakes

Haha, yeah sorry about that, I wasn’t even trying to nuke the database either but it worked out that way 😩

@prologic@twtxt.net Righteo, so rookie error - I obviously had some untracked, rather important files for starting my pod and I ran a make clean. Why I originally had them in the git directory is anyone’s guess. Anyway it blew away those files including the database so that’s that. So your good self and @bender@twtxt.net etc - apologies but your profiles got nuked as well (as did my own but easily recreated).

Another thing I noticed which was the reason I ran make clean in the first place. I noticed my pod was being built with Go 1.22.4. Could this be a problem @prologic? preflight.sh actually errors out about it…

@bender@twtxt.net I have nothing against GoToSocial, but:

GoToSocial stores statuses, accounts, etc, in a database. This can be either SQLite or Postgres.

snac is simpler. Some JSON files and that’s it. I can read them with jq and less. I can use tar to back them up. I can hand edit them in a text editor.

I think @abucci@anthony.buc.ci and @stigatle@yarn.stigatle.no are running snac? I didn’t have a closer look at snac (no intention of running it), but if that is a relatively small daemon (maybe comparable to Yarn?) that gives you access to the whole world of ActivityPub, then, well, yeah … That’s tough to beat.

Yes, I am running snac on the same VPS where I run my yarn pod. I heard of it from @stigatle@yarn.stigatle.no, so blame him 😏 snac is written in C and is one simple executable, uses very little resources on the server, and stores everything in JSON files (no databases or other integrations; easy to save and migrate your data) . It’s definitely like yarn in that respect.

I haven’t been around yarn much lately. Part of that is that I’ve been very busy at work and home and only have a limited time to spend goofing off on a social network. Part of it is that I’m finding snac very useful: I’ve connected with friends I’d previously lost touch with, I’ve found useful work-related information, I’ve found colleagues to follow, and even found interesting conferences to attend. There’s a lot more going on over there.

I guess if I had to put it simply, I’d say I have limited time to play and there are more kids in the ActivityPub sandbox than this one. That’s not a ding on yarn–I like yarn and twtxt–I’m just time constrained.

@mckinley@twtxt.net I can’t say for sure. I didn’t even know how three-way merges work till I looked it up. I guess it’s more of git thing that would prove useful in the case of using passwordstore/pass.
As for Keepass, all I do is syncing it’s database file across devices using syncting. Never felt the need to try anything else.

I guess it is safe enough for my use case, with Backup database before saving on and custom Backup Path Placeholders as Backup plan in case of an Eff up.

@shreyan@twtxt.net ever tried KeepassXC or Pass/Password Store ? They are worth giving a try … Then you can keep your KeepassXD database in synch across your devices with (NOT /R/s/y/n/c) I meant Syncthing or git in the case Pass (using a git repo in within your local network of course) 👍🏼(edited)

Thinking of building a simple “Things our kids say” database form, using Node, Express and SQlite3. Going beyond simple text files.

Markdown + Git as a database / object store? 🤔

From my small experience in writing an event database, I am inclined to agree with this.

If you’re looking for a cool p2p database system have a look at www.earthstar-project.org

@abucci@anthony.buc.ci Where did I hate on SQL databases? 🤔

@lyse@lyse.isobeef.org flawed is the right word, no harsh at all. Good reading, and thanks for supporting the possibility of convincing @prologic@twtxt.net to switch to a database! :-D :-P

@eldersnake@we.loveprivacy.club Several reasons:

• It’s another language to learn (SQL)
  
• It adds another dependency to your system
  
• It’s another failure mode (database blows up, scheme changes, indexs, etc)
  
• It increases security problems (now you have to worry about being SQL-safe)
  

And most of all, in my experience, it doesn’t actually solve any problems that a good key/value store can solve with good indexes and good data structures. I’m just no longer a fan, I used to use MySQL, SQLite, etc back in the day, these days, nope I wouldn’t even go anywhere near a database (for my own projects) if I can help it – It’s just another thing that can fail, another operational overhead.

Hi, I am playing with making an event sourcing database. Its super alpha but I thought I would share since others are talking about databases and such.

It’s super basic. Using tidwall/wal as the disk backing. The first use case I am playing with is an implementation of msgbus. I can post events to it and read them back in reverse order.

I plan to expand it to handle other event sourcing type things like aggregates and projections.

Find it here: sour-is/ev

@prologic@twtxt.net @movq@www.uninformativ.de @lyse@lyse.isobeef.org

The complexity is a feature. It means standards can be replaced with products that let providers get their cut. It means putting data into the slowest most expensive database in cost and enviromnmental impact.

You’ve basically already left, whether you know it or not. Yesterday they nuked their services database. I’d been there ~20 years, but it’s dead. Libera.chat has been lovely.

Think of it like buying a signed print of a photo, instead of the photo itself, but the “signature” is an entry in a database and that’s all you get. Still dumb.