02 — Process
How it was built
Building a social network where no single person is in charge sounds simple, but it creates an immediate problem: how do you get completely separate systems, built by different teams, to talk to each other reliably? We solved this with a shared rulebook. Every action on the platform gets packaged into a small, labelled message and delivered directly to the right person's inbox on whichever server they live on. It works a bit like email: you don't need to be on the same provider as someone to send them a message, you just need to know their address.
The hardest part wasn't writing the code, it was working with five other teams who were building their own
versions of the same system. When we sat down to connect our servers together, we found we'd all made
slightly
different assumptions about how things should be formatted. We had to negotiate a common standard
mid-project
and update our database structure without breaking everything that already worked.
On the front end, the challenge was taking all those messages arriving from different servers, each
formatted
slightly differently, and turning them into a single, clean feed that just looks like a normal social media
timeline.
The database had to account for the fact that users live on different servers. Rather than copying everyone's profile data and keeping it up to date everywhere, we gave every person a permanent web address that works as their unique ID across the whole network, no matter which server you're on, that address always points back to the right person. The schema was designed around eight core models across 2 Django applications, AuthorApp and PostApp, ensuring clean handling of concerns across the local and remote boundary.
The trickiest design problem was representing remote authors. Rather than duplicating profile data from other nodes, each remote author is identified by a composite URL built from their home node's identifier and username. This gave us a stable, dereferenceable key for cross-node references without the consistency problems that come from copying data you don't own.
Every action on the platform is represented as a typed JSON object and delivered by POST to the recipient's inbox endpoint via HTTP protocol. The sending node is responsible for routing public posts go to every follower's inbox, friends-only posts go to mutual follows only. All nodes require administrators to initiate a handshake and verify each other via the API. This ensured only the necessary information was being shared across nodes and increased the users control over who saw their account.
The inbox endpoint is an append queue for each node. No logic runs on delivery, objects are stored as-is and processed on read to reduce overhead. This keeps the receiving node passive and makes the system easier to reason about: each node only needs to trust its own data, not the correctness of remote processing.
A significant schema restructure was necessary after cross-team API discussions surfaced incompatibilities in how nodes were modelling shared objects. Coordinating that migration across an active codebase without breaking existing endpoints was one of the more demanding parts of the project.
Early on I created clean and flexible Figma prototypes to work towards. This lead the groundwork for how we handled the user flow and Django Views. To reduce redundancy I created HTMX templates. This decrease te umber of HTML files to maintain and simplified our workflow
The stream is a merged view much like instagram. All posts, comments and likes are all pulled together into a single chronological feed. Rather than surfacing raw events, each object type renders as a notification feed item, a like appears as a post with its reaction context, a follow request as an actionable card, keeping the experience readable without hiding activity and streamlining actionable items
Overall, the aim was to create a user flow and interface that was familiar for our users, while still being flexible enough to integrate the posts of other systems
The main challenge was normalizing content from five external nodes, each with slightly different field shapes and image handling. Rendering had to be defensive: missing fields fell back gracefully, and images were validated before display rather than assumed present.