Expose external accounts as virtual Org Social feeds that any client
can follow with a plain #+FOLLOW: line:
- /bridge/activitypub/@{user}@{instance}/ bridges a Mastodon or any
ActivityPub account (WebFinger, actor and paginated outbox; only
public top-level notes, with CW, hashtags, language and attachments)
- /bridge/rss/?url={feed} bridges any RSS/Atom feed (entry title as
*** sub-heading, converted body and link to the original article)
Registration is implicit on first GET. Bridged data is stored in the
existing Profile/Post tables so /profile/, /search/ and the rest of
the API work on bridged feeds. Active bridges are refreshed every 15
minutes; bridges unrequested for 90 days are cleaned up.
Remote HTML is converted to Org text, escaping headline-like lines so
external content cannot inject posts. Fetches enforce the Webmention
SSRF protections, a 10s timeout and a 5MB size cap. Bridged posts
never queue Webmentions nor publish notifications.
Implements the sender side of https://www.w3.org/TR/webmention/. During
feed scans, external URLs found in new posts (and links added by edits)
are queued as OutgoingWebmention rows; a periodic task discovers each
target's endpoint and delivers the notification. The unique
(source, target) pair guarantees a webmention is sent at most once, no
matter how many times a feed is rescanned. Targets without an endpoint
are marked permanently, failures retry with exponential backoff, and
endpoints resolving to loopback/private addresses are rejected.
Receiving webmentions is out of scope: plain text feeds cannot
advertise an endpoint.
Without ?feed=, the endpoint subscribes to all notification channels via
Redis psubscribe("notifications:*") and adds target_feed to each event.
With ?feed=, behavior is unchanged. Updates README and root _links.
New GET /profile/?feed={url} endpoint that returns the list of feed URLs
that follow the given profile, using the existing Follow model.
Includes cache support, 400/404 error handling, and 8 unit tests.
Changed node labels from 'Node X (relay-list.txt)' to simply 'Relay X'
for cleaner visualization. Also updated Concepts section to use 'Relay'
terminology consistently throughout the documentation.
The relay list is now decentralized - each node maintains its own
local relay-list.txt file. Nodes share feeds directly with each other
in a P2P fashion, without needing a centralized list endpoint.
Changes:
- Remove 'List nodes' from mermaid diagram
- Add relay-list.txt notation to each node
- Update 'Share Users' to 'Share Feeds' for accuracy
- Simplify Concepts section to reflect decentralized architecture
The relay-list.txt file is now part of this repository, so the
instructions for making a relay public have been updated to reflect
that users should make PRs to this repo instead of the external
org-social repository.
When PRs are merged, all relay nodes that update their code will
automatically get the updated relay list.
This commit introduces three new REST API endpoints to the Org Social Relay:
1. /reactions/ - Retrieves reactions (posts with mood emojis) to a user's posts
2. /replies-to/ - Gets direct replies to a user's posts (excluding reactions and poll votes)
3. /notifications/ - Unified endpoint combining mentions, reactions, and replies with optional type filtering
Implementation details:
- All endpoints follow the existing API pattern with caching, validation, and error handling
- Comprehensive test suites with 35 passing tests
- Updated README with full documentation and examples
- Integrated into Django settings and URL configuration
- Code formatted with Ruff
🤖 Generated with [Claude Code](https://claude.com/claude-code)
