(bopwiki dev) how do I remake mastodon's cached post?

Okay, I guess out of the two questions I had that answers the specific one. I may not really like the answer mastodon had to this - I feel like it makes it a lot harder for developers like me messing with ActivityPub for the first time to test out how it works without worrying that every mistake is permanent - but I can accept it.

Now for the “general” version of the question.

This morning I was thinking about a way to dodge the post uri problem. I’d been assuming the post uri would be the url of the post’s AP/AS file, but I realised I could just add a revision number to uniquely identify which ‘attempt’ to reach the fediverse each post was on (probably always starting at 1).

so the uris become something like:
before - https://distributary.network/bop/reactions/ap-entry/1627115700
after - https://distributary.network/bop/reactions/ap-entry/1627115700_r3

Now I’m left with a more abstract problem of how to interoperate two programs/platforms that have entirely different workflows.
The way bop works, you have a folder of entries which are just simple text files. They have an entry body (the blog post etc) and a block of “meta lines” which can do various semantic things. Example:

# illustration entry

here is the body of the entry

=> 1623643359 external link
<= 1631146517 entry replied to
# pub_distri
; above is a tag to select entries to publish - this is a comment

This entry might live in a file like 1631146746_example.txt, and render to a file like /publish/path/1631146746_example.htm. (htm was a subjective choice just for reasons like the names fitting into columns better when debugging what pages were published with ls.)
When publishing as an AP/AS object it might render to a file like /publish/path/ap-entry/1631146746, or after a near-future update, maybe /.../ap-entry/1631146746_r1.

The problem is, bop is a bit minimalist and sort of aims for a file/folder structure where files are only annotated with information meaningful to the author.
It would be possible on paper to add a meta line type for ‘activitypub revision’ (1, 3, etc) but it seems like an extraneous thing to have to tack on to each entry.
It would also be possible to keep ‘extraneous’ metadata like this in separate files that attach themselves to entries, or in some kind of out-of-the-way place like a .bop directory.

One day, bop is actually intended to have rdf support, where you can specify an rdf triple subject+predicate and use that to define a new meta line or simply add a named metadata value.
But those ‘fancy’ meta lines don’t really exist yet; all the default meta line types are somewhat hardcoded at the moment and it’s been a little while since I was actively working on that part of the program.

So I’m a bit at a loss for how to test bop’s activitypub support when I mostly only use mastodon and it’s not immediately practical to get the Editable Fediverse and the Uneditable Conversation Fediverse to interoperate right now until I do a whole bunch more work on my program (possibly in the form of really ugly duct tape that’s a pain to finish properly as I fix each data folder along with the application code).

Is there another platform I can test with that actually supports updating its cache?
Like for instance, a ‘small’/‘lightweight’ activitypub server I could almost trivially install and self-host that would display the bop posts similarly enough to how mastodon does that I could be confident mastodon would interpret the data about the same way, but I could ‘refresh’ the entries, even if I have to use administrator tools to do it? (I tried looking at the documentation for how to install mastodon once, and I don’t remember the exact reason, but for some reason it was way too much for me to even try and I gave up.)

I think what I mainly mean is things like “if mastodon displays Articles as just a link and ignores the ‘content’ property, this one does too”. Though if it decided to follow the standard better than mastodon in a way that could guide me to create more standards-compliant posts that make even better uses of AP/AS features, I’d take that as well, as long as I’m not stuck using this dangling-in-the-air future version of ActivityPub actually existing platforms don’t support and may never support.