Blog · a series
Rutba Relay
Publishing to every social network from one place, and running that as infrastructure somebody else depends on: one account, switches that stop an incident, and an operator view that never shows a customer’s posts.
5 parts · about 15 minutes to read them all
Part 1 · 2 min read
Posting the same thing to six networks by hand is an hour a day nobody has
The scheduling half is well served. The part that is not: a documented API the console itself is built on, so anything else (including an assistant with the same permissions a person has) can publish the same way.
Part 2 · 3 min read
One Rutba account opens the Relay, and the Relay no longer keeps passwords of its own
The Relay used to run its own sign-up, passwords, second factor and invitations. Now a person signs in once with their Rutba account, and their organisation gives them the Relay the way it gives them anything else.
Part 3 · 3 min read
A kill switch with a name on it
When a social network changes something overnight, a publishing service can fire thousands of failing requests at it and collect strikes against your accounts. The Relay’s switches stop that, and every one records who threw it and when it clears.
Part 4 · 3 min read
The view our operators get of your Relay workspace shows its shape, not your posts
Running a publishing service means staff sometimes need to look inside a customer’s workspace. What they see is who is in it, what is connected and how recent posts went. Never a credential, and never a word of a post.
Part 5 · 4 min read
A launch morning waits ten minutes. A looping script is paused
Rutba Relay now counts the deliveries each organization started in the last hour. Just over its ceiling, a publish is told to wait ten minutes. Four times over is not a person, and that organization’s publishing is paused until somebody looks.
