Topic history & load snapshot of topic back in time

[keyserj]

Is your feature request related to a problem? Please describe. I frequently want to make large changes to a diagram while preserving the ability to see what the previous structure was. Right now, in order to do that, I need to clone the diagram, and add some suffix like "[topic-name]-refactor".

One consistent example of this is after a discourse session - wanting to preserve what we had at the end vs refactor it afterwards. Another example is when showing the difference between two ways of organizing the same information - like entirely via a claim tree vs using structure nodes.

Describe the solution you'd like Add "history" section in Topic details, perhaps with a "Create snapshot now" button, and ability to load/delete/rename snapshots. Loading a snapshot would get all the nodes and edges from that specific point in time and populate the diagram with those - to be interacted-with as if it were the current diagram (but without editing - if you want to edit, download the diagram and re-upload).

UX ideas:

• Wikipedia history and GitHub history seem like good UX inspiration, maybe even simpler for our use-case

Future but probably not now:

• Wouldn't need history per-node at this point, but that would probably also be useful (at least to see something like "text changed x->y on DD/MM/YYYY").
• History playback (button to watch how the Topic evolves over time)
• Diff between snapshots

Questions to answer

• Which models to version?
  • Yes: Node, Edge
  • Maybe?: Score
  • No: Comments
• Should snapshots be taken manually, or also automatically? Could do 1 every X (100?) changes
• Support URL version=[time] param?

Describe alternatives you've considered

Additional context

Technical ideas Probably do some googling to look into how others have implemented this type of thing. Some maybe reference materials:

• https://hn.algolia.com/?dateRange=all&page=0&prefix=false&query=data%20versioning&sort=byPopularity&type=story
• https://softwareengineering.stackexchange.com/questions/402188/database-design-maintaining-versions-of-an-object
• https://news.ycombinator.com/item?id=26748096

One idea:

• Add "created_at" and only create new records, never update
• All reads need to group by UUID and get the latest one
• Topic Snapshot just consists of a name, a topic id, and a time
• Loading a snapshot would call GetData endpoint with a time, which pulls all records based on created_at <= time

Technical Questions:

• Could make a separate [Model]Versions table to make current reads easy?
• Is there awkwardness in maintaining FKs when models are deleted?
  • I think deletion might need to be done by creating a new record that says "deleted" ("tombstone"?)? or something like that?
• How to handle data migration of old data?
  • The suggested implementation seems like it'd support performing data migration the same way on old data as current data

[keyserj]

Adding topic history and loading a snapshot seem like they should probably be designed together, but these can be split into two tickets if that seems better later.

Potentially history could be a simpler initial implementation if we didn't actually care about diffing history, and only wanted to see a string like "added X", "removed X", but diffing seems pretty valuable, especially for seeing many changes together.

[prototyperspective]

Important issue. Again, a wiki-approach would be really useful for many reasons such as transparency, familiarity, potential interoperability/embeddability, enabling related features, ability to use/adapt some of many existing wiki gadgets/scripts, good revert functionality, etc. I don't think a 'snapshot' approach is a good idea. Why not just have all the changes logged and revertable? Then one can pick any version not just a specific one where somebody created a snapshot and these can be distinguished easily via the timestamps (e.g. latest version before the discourse session). One can also see the auto-generated edit summary to differentiate between changes and pick the right version or even go through the diffs one at a time with the next diff button. If you think a snapshot-type feature would be needed what about adding the ability to tag revisions – e.g. version 0.2 to some revision after large refactoring was finished.

I don't know and haven't yet looked into how the data is stored – if it's json one could show simply diffs of the json file as if it's a normal wiki page (these diffs show only the changed parts not the whole doc). At a later point one could convert or parse it into a more readable format. For example here at the map click on source. Each node has its own history but all are part of the same json I think so the revision history for the whole problem tree would show the diffs of the entire json file. A more readable format would be e.g. replacing the diff of some changed json for a newly added connection line with "added link of type {type} between node {title of node} and node {title of node}"...or replacing the diff of an edited description of one node with just the diff of the description field value instead of the json.

This is a key component so yes it could be a bit tricky but lots of other things depend on this feature such as the ability to watch changes to bookmarked problem trees, edit reversion, user contributions pages, content attribution, functionality to list unseen changes. Below is how the unseen changes are listed on a debate site on Kialo, a per problem tree and site-wide feed could be based on these histories. When clicking on any of these cards in the sidepanel it opens the associated node in the map and marks it as seen. In Wikipedia, there is a separate Watchpage (not embedded via a sidepanel) and when going from there to the history page of an article there is a green dot next to all unseen changes to that from there one can check the changes. I think it would be best to have a History of all revisions of the problem tree (later one could do more with that) and show the unseen diffs somewhere on the problem map page. I think it makes most sense for people to go through all changes on a per node-level instead of seeing a diff of all changes at once (the map could however color all of these in some way) – the changes could be grouped by node so if a node (id 123) was added and then edited, there would only be one item in the problem map History for node 123 for users to check – nevertheless all changes would be in the Page revision history ordered chronologically but that is mostly used for reverting specific changes.