--- /dev/null
+The Borg special remote is indeed an exciting next step for this amazing
+project. I’m currently testing it with a small team. For remote collaboration,
+each of us has provisioned:
+
+- one workstation with a git-annex repo (accessible only to the workstation user)
+- one server (NAS) with a Borg repo (accessible to all team members)
+
+The idea was to implement a basic distributed topology by adding all the Borg
+repos as special remotes to all the git-annex repos. With such an implementation,
+a typical workflow would be:
+
+1. A team member:
+ **(a)** commits a change to the git-annex repo on the member’s own workstation,
+ **(b)** creates an archive of the updated git-annex repo in each of the Borg
+repos, and
+ **(c)** informs the member’s own git-annex repo of the new Borg archives by running `git annex sync`.
+2. All other team members inform their respective git-annex repos of the new
+Borg archives by simply running `git annex sync`.
+
+Step 1 worked, but Step 2 did not, so as a workaround, we added a bare
+git-annex repo alongside the Borg repo on each server, then added all the new
+bare repos as remotes to each of our respective workstation repos. It works
+but is less than ideal.
+
+My simplified question: can two git-annex repos share a Borg special remote?
+
+Joey commented back in December: “The Remote interface recently got
+importKey, which gets us unexpectedly a lot closer to making git-annex import
+--from borg a reality!” However, I’ve struggled to find any other clues.
+
+Potentially related issues (all of which appear to have been addressed):
+
+- [sync --content with borg does not get content](https://git-annex.branchable.com/todo/sync_--content_with_borg_does_not_get_content/)
+- [borg sync tree not grafted](https://git-annex.branchable.com/todo/borg_sync_tree_not_grafted/)
+- [use same vector clock for content identifier updates in import](https://git-annex.branchable.com/todo/use_same_vector_clock_for_content_identifier_updates_in_import/)
+
+Thanks!