You are absoultely right and it is the case for all activities that we generate. We do not have the activities saved in the DB and I do not know what a good way to save those would be. If we just save the json it will take up a lot of space, but would be easy to implement. If we'd save the referenced actor and object and payload etc it would take up less space, but would need a lot of logic to be implemented properly

Perhaps you can generate activities on the fly, when they are requested?
Or, alternatively, save them as JSON, and automatically delete after some time. I think in practice activities need to be dereferencable only for the brief moment when the Group actor announces them (and subscribers attempt to fetch them).

@e-five256 @nobodyatroot @melroy89 @asdfzdfj what do you think? I don't know if I'd want to delete activities again... But to save DB space it might be unavoidable...

Perhaps you can generate activities on the fly, when they are requested? Or, alternatively, save them as JSON, and automatically delete after some time. I think in practice activities need to be dereferencable only for the brief moment when the Group actor announces them (and subscribers attempt to fetch them).

imo a mix of both is probably needed, if you really want this

for the kind of activity that creates stuff e.g. Create, Like, it should be possible to "synthesize" these activity from existing data/state in the db upon request, though the path to activity object will need to change so it could be accessed properly (beats storing the uuid it just made up alongside the activity it referenced)

for the kind of activity that negates/removes stuff e.g. Delete, Undo, then caching the delivered activity for a period of time and then return those when being deref'd should be more feasible since at that point we most likely no longer have the object in question to synthesize activity for (or we would have to store those activities or its target object tombstones/sentinel values for all time which would be an absolute nightmare in more ways than one)
this does put some pressure on storage/memory but statistically (from what I could see, anyway) this should happen way less often compared to the amount of creation activities enough to be feasible (and delegating this to cache with ttls should help with cleaning up old activities)

This issue is stale because it has been open 50 days with no activity. Remove stale label or comment or this will be closed in 6 days.

Still relevant.

I solved a similar problem in my own software by caching all outgoing activities (they are automatically removed after several days).

It's still on my radar, but I don't want to implement a temporary fix, I want to solve it properly but that takes time. I have a lot of items I am currently working on, but this is not yet on that list. You should be able to see the dashboard with things we are working on here: https://github.com/orgs/MbinOrg/projects/5/views/1 (note: atm not a lot of us use the board, but I do)

Sure, this is not urgent. I just wanted to prevent stale bot from closing the issue

Sure, this is not urgent. I just wanted to prevent stale bot from closing the issue

fyi, we neutered stale bot from closing any issues. it'll say it's going to close it in x number of days, but not anymore. we don't have anyone dedicated to working on Mbin full-time, so it can be a slow process at times with work/personal schedules taking priority.