Bridgy Fed
Bridgy Fed connects your web site to Mastodon and the fediverse via ActivityPub, webmentions, and microformats2. Your site gets its own fediverse profile, posts and avatar and header and all. Bridgy Fed translates likes, reposts, mentions, follows, and more back and forth. See the user docs and developer docs for more details.
Also see the original design blog posts.
License: This project is placed in the public domain.
Development
Development reference docs are at bridgy-fed.readthedocs.io. Pull requests are welcome! Feel free to ping me in #indieweb-dev with any questions.
First, fork and clone this repo. Then, install the Google Cloud SDK and run gcloud components install beta cloud-datastore-emulator
to install the datastore emulator. Once you have them, set up your environment by running these commands in the repo root directory:
gcloud config set project bridgy-federated
python3 -m venv local
source local/bin/activate
pip install -r requirements.txt
Now, run the tests to check that everything is set up ok:
gcloud beta emulators datastore start --use-firestore-in-datastore-mode --no-store-on-disk --host-port=localhost:8089 --quiet < /dev/null >& /dev/null &
python3 -m unittest discover
Finally, run this in the repo root directory to start the web app locally:
GAE_ENV=localdev FLASK_ENV=development flask run -p 8080
If you send a pull request, please include (or update) a test for the new functionality!
If you hit an error during setup, check out the oauth-dropins Troubleshooting/FAQ section.
You may need to change granary, oauth-dropins, mf2util, or other dependencies as well as as Bridgy Fed. To do that, clone their repo locally, then install them in "source" mode with e.g.:
pip uninstall -y granary
pip install -e <path to granary>
To deploy to the production instance on App Engine - if @snarfed has added you as an owner - run:
gcloud -q beta app deploy --no-cache --project bridgy-federated *.yaml
How to add a new protocol
- Determine how you'll map the new protocol to other existing Bridgy Fed protocols, specifically identity, protocol inference, events, and operations. Add those to the existing tables in the docs in a PR. This is an important step before you start writing code.
- If the new protocol uses a new data format - which is likely - add that format to granary in a new file with functions that convert to/from ActivityStreams 1 and tests. See
nostr.py
andtest_nostr.py
for examples. - Implement the protocol in a new
.py
file as a subclass of bothProtocol
andUser
. Implement thesend
,fetch
,serve
, andtarget_for
methods fromProtocol
andreadable_id
,web_url
,ap_address
, andap_actor
fromUser
. - TODO: add a new usage section to the docs for the new protocol.
- TODO: does the new protocol need any new UI or signup functionality? Unusual, but not impossible. Add that if necessary.
- Add the new protocol's logo to
static/
, use it intemplates/user.html
.
Stats
I occasionally generate stats and graphs of usage and growth via BigQuery, like I do with Bridgy. Here's how.
-
Export the full datastore to Google Cloud Storage. Include all entities except
MagicKey
. Check to see if any new kinds have been added since the last time this command was run.gcloud datastore export --async gs://bridgy-federated.appspot.com/stats/ --kinds Follower,Object
Note that
--kinds
is required. From the export docs:Data exported without specifying an entity filter cannot be loaded into BigQuery.
-
Wait for it to be done with
gcloud datastore operations list | grep done
. -
for kind in Follower Object; do bq load --replace --nosync --source_format=DATASTORE_BACKUP datastore.$kind gs://bridgy-federated.appspot.com/stats/all_namespaces/kind_$kind/all_namespaces_kind_$kind.export_metadata done
-
Check the jobs with
bq ls -j
, then wait for them withbq wait
. -
Run the full stats BigQuery query. Download the results as CSV.
-
Open the stats spreadsheet. Import the CSV, replacing the data sheet.
-
Check out the graphs! Save full size images with OS or browser screenshots, thumbnails with the Download Chart button.