pleroma=# select data->>'content', inserted_at, data->>'id' from objects where data->>'actor' = 'https://gleasonator.com/users/alex' and data->>'content' ilike '%migrat%' and ( data->>'content' ilike '%rebased%' or data->>'content' ilike '%pleroma%' or data->>'content' ilike '%ditto%'); | inserted_at | ?column? ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ----------------------------------------------------------------+---------------------+---------------------------------------------------------------------- @eris @Moon In theory the official way to do this would be to figure out the first migration Akkoma introduced, and rollback the migrations to before that point. You could then, in theory, git checkout pleroma a nd then migrate forward.

However, I would not assume that would just work. I would first look at all the migrations Akkoma introduced to get a picture of it. I would pull the database locally and attempt the change before taking down the prod site.

It could be straig htforward. But my personal experience tells me it's going to be a bit more complicated, because it never is easy. If you're not dealing with problems related to the migrations themselves, you're dealing with problems with different versions of Pleroma wanting different versions of Elixir and other dependencies as you switch between commits. It just seems like an easy way to ruin your weekend when you could just not. Instead, set up a local dev environment and pull the database down, try the conversion there. If it works, awesome. If it doesn 9;t, oh well! didn't needlessly create stress for yourself. | 2023-06-09 20:59:20 | https://gleasonator.com/objects/4f9ef89c-f8cd-4615-877b-a197a106472a @5e336907a3dda5cd58f11d162d8a4c9388f9cfb2f8dc4b469c8151e379 c63bc9 Yep. I had that idea today and I guess it got floated around. We need to build a tool to let users migrate from ActivityPub to Nostr. https://gitlab.com/soapbox-pub/ditto/-/issues/ 31

Once Ditto is functional I will build this. | 2023-07-30 22:57:44 | https://gleasonator.com/objects/8c2fcb66-9666-47c1-a86c-a574c9f48873 @i @lain @guizzy @mangeurdenuage Upgrade to Postgres 14. It will fix it. Also, run pg_repack. I created this post for that very migration specifically.

https://gitlab.com/soapbox-pub/rebased/-/snippets/2463995 | 2023-08-07 16:30:59 | https://gleasonator.com/objects/fd393681-919f-4736-ae38-4617d90dd789 Here's what I've been working on the past few days: processing deletions.

https://gitlab.com/soapbox-pub/ditto/-/merge_requests/36

- Add a deleteFilters function to delete event s by filter from the database
- Reworked the `tags` database table, renamed `value_1` to `value`, dropped `value_2`, `value_3`, added a foreign key on `event_id`
- Enabled autovacuum on the database.
- Automatically delete events older than 7 days. Fixes #63
- Broadcas t deletions from local users to all known relays.
- Process deletion events through the pipeline, delete from our database if authorized.
- Protect against deleted events being resubmitted (not perfect).
- Improved the terminal output for migrations.
- Fix various bugs . | 2023-09-06 03:20:30 | https://gleasonator.com/objects/0c9d9f46-a139-45df-8359-56c447068549 @feld I don't want to write my own query planner. I'm amazed that people have act ually done it. It gets real complicated when you have 3+ overlapping criteria. Either you need compound indexes or you need to load multiple entire datasets into memory and intersect them. I ain't got the time or willpower for that. Plus no migrations. It would be fragile for a bigger project like Ditto, unlike strfry which is laser-focused on implementing just the Nostr relay interface. It seems to make sense to use SQLite for queries, and LMDB for counter stats, pregenerated feeds, and other cache. I think between the two of them you could build a tr uly production-ready application even though it's unusual. | 2023-12-07 19:22:24 | https://gleasonator.com/objects/8827fbb8-e7cc-48fe-a69a-676e63764289 (5 rows) pleroma=#