Bridgy developer documentation

Got a web site? Want social network replies and likes on your site? Want to post and tweet from your site? Bridgy is for you.

Bridgy pulls comments and likes from social networks back to your web site. You can also use it to publish your posts to those networks. See the user docs for more details, or the developer docs if you want to contribute.

License: This project is placed in the public domain.


You’ll need the App Engine Python SDK version 1.9.15 or later (for vendor support). Add it to your $PYTHONPATH, e.g. export PYTHONPATH=$PYTHONPATH:/usr/local/google_appengine, and then run:

virtualenv local
source local/bin/activate
pip install -r requirements.freeze.txt

# We install gdata in source mode, and App Engine doesn't follow .egg-link
# files, so add a symlink to it.
ln -s ../../../src/gdata/src/gdata local/lib/python2.7/site-packages/gdata
ln -s ../../../src/gdata/src/atom local/lib/python2.7/site-packages/atom

python -m unittest discover

The last command runs the unit tests. If you send a pull request, please include (or update) a test for the new functionality if possible!

If you hit an error during setup, check out the oauth-dropins Troubleshooting/FAQ section. For searchability, here are a handful of error messages that have solutions there:

bash: ./bin/easy_install: ...bad interpreter: No such file or directory

ImportError: cannot import name certs

ImportError: No module named dev_appserver

ImportError: cannot import name tweepy

File ".../site-packages/tweepy/", line 68, in _get_request_token
  raise TweepError(e)
TweepError: must be _socket.socket, not socket

error: option --home not recognized

There’s a good chance you’ll need to make changes to granary, oauth-dropins, or webmention-tools at the same time as bridgy. To do that, clone their repos elsewhere, then install them in “source” mode with:

pip uninstall -y oauth-dropins
pip install -e <path to oauth-dropins>
ln -s <path to oauth-dropins>/oauth_dropins \

pip uninstall -y granary
pip install -e <path to granary>
ln -s <path to granary>/granary \

pip uninstall -y webmentiontools
# webmention-tools isn't in pypi
ln -s <path to webmention-tools>/webmentiontools \

The symlinks are necessary because App Engine’s vendor module evidently doesn’t follow .egg-link or .pth files. :/

To deploy to App Engine, run scripts/

remote_api_shell is a useful interactive Python shell that can interact with the production app’s datastore, memcache, etc. To use it, create a service account and download its JSON credentials, put it somewhere safe, and put its path in your GOOGLE_APPLICATION_CREDENTIALS environment variable.

Adding a new silo

So you want to add a new silo? Maybe MySpace, or Friendster, or even Tinder? Great! Here are the steps to do it. It looks like a lot, but it’s not that bad, honest.

  1. Find the silo’s API docs and check that it can do what Bridgy needs. At minimum, it should be able to get a user’s posts and their comments, likes, and reposts, depending on which of those the silo supports. If you want publish support, it should also be able to create posts, comments, likes, reposts, and/or RSVPs.
  2. Fork and clone this repo.
  3. Create an app (aka client) in the silo’s developer console, grab your app’s id (aka key) and secret, put them into new local files in the repo root dir, following this pattern. You’ll eventually want to send them to @snarfed and @kylewm too, but no hurry.
  4. Add the silo to oauth-dropins if it’s not already there:
    1. Add a new .py file for your silo with an auth model and handler classes. Follow the existing examples.
    2. Add a button image.
    3. Add it to the app front page and the README.
  5. Add the silo to granary:
    1. Add a new .py file for your silo. Follow the existing examples. At minimum, you’ll need to implement get_activities_response and convert your silo’s API data to ActivityStreams.
    2. Add a new unit test file and write some tests!
    3. Add it to (specifically Handler.get),, app.yaml, index.html, and the README.
  6. Add the silo to Bridgy:
    1. Add a new .py file for your silo with a model class. Follow the existing examples.
    2. Add it to, app.yaml, and, (just import the module).
    3. Add a 24x24 PNG icon to static/.
    4. Add new SILO_signup.html and SILO_user.html files in templates/. and add the silo to listen_signup.html. Follow the existing examples.
    5. Add the silo to about.html and this README.
    6. If users’ profile picture URLs can change, add a cron job that updates them to and cron.yaml. Also add the model class to the datastore backup job there.
  7. Optionally add publish support:
    1. Implement create and preview_create for the silo in granary.
    2. Add the silo to import its module, add it to SOURCES, and update this error message.
    3. Add a publish-signup block to SILO_user.html and add the silo to social_user.html.
    4. Update app.yaml.

Good luck, and happy hacking!


App Engine’s built in dashboard and log browser are pretty good for interactive monitoring and debugging.

For alerting, we’ve set up Google Cloud Monitoring (née Stackdriver). Background in issue 377. It sends alerts by email and SMS when HTTP 4xx responses average >.1qps or 5xx >.05qps, latency averages >15s, or instance count averages >5 over the last 15m window.


The datastore is automatically backed up by a cron job that runs Datastore Admin backup and stores the results in Cloud Storage, in the bucket. It backs up all entities monthly, and all entities except Response and SyndicatedPost weekly, since they make up 92% of all entities by size and they aren’t as critical to keep.

We use this command to set a Cloud Storage lifecycle policy on that bucket that prunes older backups:

gsutil lifecycle set cloud_storage_lifecycle.json gs://

Run this to see how much space we’re currently using:

gsutil du -hsc gs://\*

Run this to download a single complete backup, for e.g. generating usage metrics with

gsutil -m cp -r gs://\* .