Skip to content

Latest commit

 

History

History
220 lines (146 loc) · 8.68 KB

bridgy.md

File metadata and controls

220 lines (146 loc) · 8.68 KB

Bridgy

Bridgy is a service that sends comments, likes, RSVPs inside social networks (aka silos) to personal web sites. It can also publish (aka POSSE) posts from personal web sites into the silos, using an interactive web UI or webmention. More details: https://brid.gy/about

Implementation Home Page URL: https://brid.gy/

Source Code repo URL(s) (optional): https://github.com/snarfed/bridgy

  • 100% open source implementation

Programming Language(s): Python

Developer(s):

Implementation Classes: Sender and Receiver

Sending

Discovery Tests (3.1.1)

MUST

Sending Tests (3.1.2)

MUST

  • Accepts HTTP 200 response as a success
  • Accepts HTTP 201 response as a success
  • Accepts HTTP 202 response as a success

Update Tests (3.1.3)

SHOULD

Bridgy does resend webmentions when responses change, but silo responses are separate from the posts they're responding to, so Bridgy doesn't currently update the webmention targets it sends to. It may in the future. Background: snarfed/bridgy#9

Delete Tests (3.1.4)

SHOULD

Not yet supported: snarfed/bridgy#9

Security Considerations (4)

  • The sender avoids sending a Webmention to a loopback address (SHOULD)

Bridgy intentionally supports loopback addresses (e.g. localhost) as an internal development tool.

Extensions

This implementation has also implemented the following extensions.

Implementation notes

Bridgy is fairly high volume (https://brid.gy/#stats), so it has a couple scaling optimizations that aren't strictly kosher:

Receiving

Indicate which type of response the receiver provides:

  • HTTP 200 - Receiver synchronously processes the Webmention request (not recommended)
  • HTTP 201 - Receiver creates a status URL the sender can use to check the status of the Webmention
  • HTTP 202 - Receiver processes the Webmention asynchronously

Bridgy processes webmention requests synchronously, but returns HTTP 201 on success. The status URL is the URL of the silo post that was created.

Describe the response body (if any) which is returned in the request:

From https://brid.gy/about#response :

JSON response containing at least a url field that points to the silo object that it operated on. The same URL is included in the Location HTTP header. For Twitter favorites and Facebook event RSVPs, this is the tweet, post, or event. If a new object was created, e.g. a Facebook post or Twitter tweet, @-reply, or retweet, there will also be an id field with the silo id of that object.

For example, this request for an original post:

POST source=https://example.com/posts/123
     &target=https://brid.gy/publish/facebook

will receive this response:

HTTP/1.1 201 Created
Content-Type: application/json
Location: http://facebook.com/456_789

{
  "url": "http://facebook.com/456_789",
  "type": "post",
  "id": "456_789"
}

Request Verification (3.2.1)

  • Verifies source and target are valid URLs, rejecting with HTTP 400 (MUST)
  • Verifies that target is a valid resource for which the receiver accepts Webmentions, rejecting with HTTP 400 (SHOULD)
  • Ignores fragment when checking if target is supported (SHOULD)

Webmention Verification (3.2.2)

  • Verification is processed asynchronously (SHOULD)
  • Follows at least one HTTP redirect on source URL (MUST)
  • Respects a self-imposed limit on number of HTTP redirects to follow (MUST)

Source URL content-types supported

Please list the content types that your implementation supports when checking if the source document links to the target URL.

  • HTML
  • Other: text/plain

HTML Verification (3.2.2)

The tests below apply when the source document is HTML.

  • Accepts a Webmention where the target URL is in an <a> tag
  • Accepts a Webmention where the target URL is in an <img> tag
  • Accepts a Webmention where the target URL is in an <video> tag
  • Accepts a Webmention where the target URL is in an <audio> tag
  • Rejects a Webmention where the target URL is in the document as text
  • Rejects a Webmention where the target URL is in an <a> tag inside an HTML comment
  • Rejects a Webmention where the target URL is not in the document

Webmention Display/Use

  • The receiver displays data from the source URL on the target post (MAY)

  • The receiver recognizes that the source URL is a "comment" or "reply" to the post

  • using HTML markup: class="u-in-reply-to"

  • The receiver recognizes that the source URL is a "like" of the post

  • using HTML markup: class="u-like-of"

  • The receiver recognizes that the source URL is a "repost" of the post

  • using HTML markup: class="u-repost-of"

  • The receiver recognizes that the source URL is an "RSVP" to the post

  • using HTML markup: class="p-rsvp" + class="u-in-reply-to"

  • The receiver recognizes additional response types, using markup:

  • picture, using HTML markup: class="u-photo"

  • person tag, using HTML markup: class="u-category h-card"

  • custom option: disable backlink in created post, using HTML markup: class="p-bridgy-omit-link"

  • custom option: ignore text formatting, using HTML markup: class="u-bridgy-ignore-formatting"

  • custom option: explicit post text, using HTML markup: class="u-bridgy-[SILO]-text"

More details: https://brid.gy/about#publishing

Update Tests (3.2.4)

  • Does not display an update Webmention as a new response (SHOULD)
  • Removes the response when an update Webmention is sent and the source URL returns 200 and no link is found (SHOULD)
  • Updates and stores the information from the primary object at the source URL (MUST)
  • Updates and stores the information from children or descendant objects at the source URL (MAY)

Not yet supported: snarfed/bridgy#84

Delete Tests (3.2.4)

  • Recognizes an HTTP 410 response as a delete, and removes the response (SHOULD)

Not yet supported: snarfed/bridgy#84

Security Considerations (4)

  • Webmentions are moderated before being displayed (MAY)
  • Webmentions are periodically re-verified (MAY)
  • The receiver ensures any displayed data it properly encoded/filtered to prevent XSS attacks (MUST)
  • Respects a self-imposed limit on the time spent fetching the source URL (SHOULD)
  • Respects a self-imposed limit on the number of bytes fetched from the source URL (SHOULD)
  • The receiver accepts additional parameters or headers, and so has CSRF protection (SHOULD)

Extensions

This implementation has also implemented the following extensions.