@jdt This may end up being the difference between:let content_type = get_header("content-type"); …and… let content_type = request.content_type().map(|x| x.to_string()); In the first, I'm using a function that interacts with the headers() map directly. In the second (which is what I had been using), I'm passing the processing through Rocket's ContentType struct. I think that may be where my problem lies. Rebuilding now.

I can be wry about the TikTok situation because I have literally never installed that app and its absence has zero impact on me or my family (in fact, I'll be pleased to not have it show up in any search results).…but it sets a precedent that might wind up being a huge pain in the neck for me (as the CTO of a small ISP that deploys TP-Link devices for CPE in high density deployments) if the government goes through with banning TP-Link devices due to trumped up characterizations of their relative vulnerability levels and susceptibility to CCP influence. I'll have opinions about that.

…and nothing of value was lost.

#Enigmatick's timeline retrieval performance was getting a little slow, so I spent some time optimizing my PostgreSQL queries yesterday. I was able to take the EXPLAIN ANALYZE loop from 17 seconds (an exaggeration of the actual experience in production of a delay of about 2 seconds) to 53ms. It was mostly down to a JOIN that employs a JSONB_AGG to pull in Actor records associated with an Activity to avoid having to make additional calls. The way I was matching against the attributed_to JSONB column was apparently slowing things down.I also have some #Wasm calls that proactively transform #E2EE asymmetrically encrypted messages to symmetrically encrypted vault items. Those run on each load of the timeline, but I was able to use spawn_local to move the processing to a background task for timeline views that don't display encrypted content.

Integrating the shared jdt_activity_pub #RustLang crate used by the backend #Enigmatick server into the frontend #Wasm component. Necessarily broke a couple of Vodozemac functions, but those will be replaced by #OpenMLS shortly.

I'm redesigning my #E2EE architecture to use #OpenMLS instead of Vodozemac. Inertia seems to be with the former and I'd like to see #ActivityPub stay at the forefront.I should have a working proof-of-concept soon. The big challenge seems to be with persistence; with Vodozemac, I could maintain a separate session record for each conversation. With MLS, all of the Groups are maintained in a single storage object for each user. And that storage is not designed with web server persistence in mind, so I've had to get a little creative. I think I can make it work. You can follow along here.

@alyxshang Most everything with #Enigmatick is in #Rust. The core is built on Rocket. The web interface is #Svelte, but it relies heavily on a client-side #WASM component built in Rust as well.My #ActivityPub structs can be found here if they're of any use to you. The Mitra and Lemmy projects are also Rust and might provide some useful inspiration.

I've become increasingly weary of the task of keeping my backend and #WASM structs aligned. So I decided to break #Enigmatick's #ActivityPub structs out into their own crate that I can use in both places. I have the Inbox and Outbox traits moved over into my core crate and just need to complete the removal of any dependencies on the data model structs.Maybe this AP-focused crate can help other #Rust #Fediverse devs eventually.

A beautiful thing about the #Fediverse is that you can interact with it however you want. If you want a dark interface with flashes of red, goldenrod, and blue - no one is going to stop you. And you want to do it all with #WASM in your browser? That's fine. And you want #E2EE? Go for it. You want to do it with #SvelteKit and #RustLang? Fine. Whatever.None of it is a trivial undertaking, of course. Although if you just want to interact with #ActivityPub from a database (or JSON files) and curl, you could build something over a weekend (see my older #SofaPub code for an example). Threads and Bluesky really hold no interest for me. I exist on Threads solely so that I can be there in there event they actually do something interesting with ActivityPub integration (they're pretty damn slow about it, though). Until I can tell my non-technical friends on Threads to follow me here on #Enigmatick and they don't have to jump through a bunch of hoops, I'm skeptical. Bluesky… meh.

I'm growing more confident in being able to use #Enigmatick on a day-to-day basis, so expect to see more Follow requests from my user account here.I'll keep my @justin account because it's always useful to have a Mastodon instance for testing. I won't be migrating as much as just duplicating. Hopefully that's okay with y'all. I do plan to figure out account migrations at some point because it doesn't look all that difficult. It's just not a priority for me right now. Re-establishing sqlite functionality is more in my sights. It looks like JSONB support has improved considerably since I did anything with it, so it may be easier than it was. The challenge I had before was managing two types of structs: one using serde_json::Value fields for Postgresql JSONB columns, and one using String fields for Sqlite TEXT columns. That's a real hassle; hopefully I can improve things.