From 2333a02b4ff11c7df6bc65217456461cfad275d4 Mon Sep 17 00:00:00 2001
From: Michael Zhang <iptq@protonmail.com>
Date: Wed, 22 Apr 2020 02:44:26 -0500
Subject: [PATCH] federation?

---
 async-git/run-tests.sh |  2 +-
 docs/federation.md     | 39 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 40 insertions(+), 1 deletion(-)
 create mode 100644 docs/federation.md

diff --git a/async-git/run-tests.sh b/async-git/run-tests.sh
index 3159c22..4497cc3 100755
--- a/async-git/run-tests.sh
+++ b/async-git/run-tests.sh
@@ -8,4 +8,4 @@ export TESTS_DIR=${TESTS_DIR:-$DIR/tests}
 for script in $(ls $TESTS_DIR/test-*.sh);
 do
     (cd $TESTS_DIR; bash $script)
-done
\ No newline at end of file
+done
diff --git a/docs/federation.md b/docs/federation.md
new file mode 100644
index 0000000..576dad0
--- /dev/null
+++ b/docs/federation.md
@@ -0,0 +1,39 @@
+federation api
+==============
+
+fedapi version: 0
+
+fedhub instances may communicate with each other via the following federation APIs, dubbed fedapi. This enables fedhub users to fully take advantage of familiar forge features while still remaining completely self-hosted.
+
+The API described here is under `/api/federation/v{#}`, since `/api` may be used by other instances for other API-related endpoints. The idea of federation is that non-fedhub instances that still respect fedapi may still communicated with fedhub instances.
+
+issues
+------
+
+Issues are usually used for tracking bugs. In fedapi, issues are authoritatively stored on the server of the host that owns the repo. Issue creators may optionally keep a record of
+
+- `/api/federation/v0/room`
+
+pull requests
+-------------
+
+comments
+--------
+
+security
+========
+
+Federation opens many vectors of attack. Think about everything that made email hard. Yep.
+
+junk
+----
+
+This problem is related to people posting massive amounts of nonsensical or inflammatory content that makes it onto public pages. Although it should be made clear such messages are posted by external creators, it's still extremely vexing to have junk cluttering up issue and pull request listings.
+
+One of the ideas tossed around earlier to mitigate this would be to have "recognized" lists of user/host combinations. For example, if user `foo@bar.host` were to interact with my repository for the first time, I would manually approve or deny this request, and then optionally add either their user/host or just their host to a whitelist. This would not be a part of the federation API.
+
+Another idea is using [hashcash][1], a proof of work system to prevent abuse. This only mitigates the volume of traffic, but not the contents. Also, making everyone perform nontrivially-expensive computations before adding any issues or comments seems nasty, but if it's used for email then it can't be too bad, right?
+
+More thoughts to follow.
+
+[1]: http://www.hashcash.org/