- Notifications
You must be signed in to change notification settings - Fork0
A simple Ruby server using Sinatra that serves Bluesky custom feeds
License
mackuba/blue_factory
Folders and files
Name | Name | Last commit message | Last commit date | |
---|---|---|---|---|
Repository files navigation
A Ruby gem for hosting custom feeds for Bluesky.
Note
ATProto Ruby gems collection:skyfall |blue_factory |minisky |didkit
BlueFactory is a Ruby library which helps you build a web service that hosts custom feeds a.k.a. "feed generators" for the Bluesky social network. It implements a simple HTTP server based onSinatra which provides the required endpoints for the feed generator interface. You need to provide the content for the feed by making a query to your preferred local database.
A feed server will usually be run together with a second piece of code that streams posts from the Bluesky "firehose" stream, runs them through some kind of filter and saves some or all of them to the database. To build that part, you can use my other Ruby gemSkyfall.
gem install blue_factory
The server is configured through theBlueFactory
module. The two required settings are:
publisher_did
- DID identifier of the account that you will publish the feed on (the string that starts withdid:plc:...
)hostname
- the hostname on which the feed service will be run
You also need to configure at least one feed by passing a feed key and a feed object. The key is the identifier that will appear at the end of the feed URI - it must only contain characters that are valid in URLs (preferably all lowercase) and it can't be longer than 15 characters. The object is anything that implements the single required methodget_posts
(could be a class, a module or an instance).
So a simple setup could look like this:
require'blue_factory'BlueFactory.set:publisher_did,'did:plc:loremipsumqwerty'BlueFactory.set:hostname,'feeds.example.com'BlueFactory.add_feed'starwars',StarWarsFeed.new
Theget_posts
method of the feed object should:
- accept a
params
argument which is a hash with fields::feed
,:cursor
and:limit
(the last two are optional) - optionally, accept a second
current_user
argument which is a string with the authenticated user's DID (depends on authentication config -see below) - return a hash with two fields:
:cursor
and:posts
The:feed
is theat://
URI of the feed. The:cursor
param, if included, should be a cursor returned by your feed from one of the previous requests, so it should be in the format used by the same function - but anyone can call the endpoint with any params, so you should validate it. The cursor is used for pagination to provide more pages further down in the feed (the first request to load the top of the feed doesn't include a cursor).
The:limit
, if included, should be a numeric value specifying the number of posts to return, and you should return at most that many posts in response. According to the spec, the maximum allowed value for the limit is 100, but again, you should verify this. The default limit is 50.
The:cursor
that you return is some kind of string that encodes the offset in the feed for a request for the next page. The structure of the cursor is something for you to decide, and it could possibly be a very long string (the actual length limit is uncertain). See the readme of the officialfeed-generator repo for some guidelines on how to construct cursor strings.
And finally, the:posts
value should be an array of posts, returned asat://
URI strings only. The Bluesky server that makes the request for the feed will provide all the other data for the posts based on the URIs you return.
If you determine that the request is somehow invalid (e.g. the cursor doesn't match what you expect), you can also raise aBlueFactory::InvalidRequestError
error, which will return a JSON error message with status 400.
An example implementation could look like this:
require'time'classStarWarsFeeddefget_posts(params,current_user=nil)limit=check_query_limit(params)query=Post.select('uri, time').order('time DESC').limit(limit)ifparams[:cursor].to_s !=""time=Time.at(params[:cursor].to_i)query=query.where("time < ?",time)endposts=query.to_alast=posts.lastcursor=last &&last.time.to_i.to_s{cursor:cursor,posts:posts.map(&:uri)}enddefcheck_query_limit(params)ifparams[:limit]limit=params[:limit].to_i(limit <0) ?0 :(limit >MAX_LIMIT ?MAX_LIMIT :limit)elseDEFAULT_LIMITendendend
The server itself is run using theBlueFactory::Server
class, which is a subclass ofSinatra::Base
and is used as described in theSinatra documentation (as a "modular application").
In development, you can launch it using:
BlueFactory::Server.run!
In production, you will probably want to create aconfig.ru
file that instead runs it from the Rack interface:
runBlueFactory::Server
Then, you would configure your preferred Ruby app server like Passenger, Unicorn or Puma to run the server using that config file and configure the main HTTP server (Nginx, Apache) to route requests on the given hostname to that app server.
As an example, an Nginx configuration for a site that runs the server via Passenger could look something like this:
server { server_name feeds.example.com; listen 443 ssl; passenger_enabled on; root /var/www/feeds/current/public; ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; access_log /var/log/nginx/feeds-access.log combined buffer=16k flush=10s; error_log /var/log/nginx/feeds-error.log;}
Feeds are authenticated using a technology calledJSON Web Tokens. If a user is logged in, when they open, refresh or scroll down a feed in their app, requests are made to the feed service from the Bluesky network's IP address with user's authentication token in theAuthorization
HTTP header. (This is not the same kind of token as the access token that you use to make API calls - it does not let you perform any actions on user's behalf.)
At the moment, Blue Factory handles authentication in a very simplified way - it extracts the user's DID from the authentication header, but it does not verify the signature. This means that anyone with some programming knowledge can trivially prepare a fake token and make requests to thegetFeedSkeleton
endpoint as a different user.
As such, this authentication should not be used for anything critical. It may be used for things like logging, analytics, or as "security by obscurity" to just discourage others from accessing the feed in the app. You can also use this to build personalized feeds, as long as it's not a problem that the user DID may be fake.
To use this simple authentication, set theenable_unsafe_auth
option:
BlueFactory.set:enable_unsafe_auth,true
The user's DID extracted from the token is passed as a second argument to#get_posts
. You may, for example, return an empty list when the user is not authorized to use it:
classHiddenFeeddefget_posts(params,current_user)ifAUTHORIZED_USERS.include?(current_user)# ...else{posts:[]}endendend
Alternatively, you can raise aBlueFactory::AuthorizationError
with an optional custom message. This will return a 401 status response to the Bluesky app, which will make it display the pink error banner in the app:
classHiddenFeeddefget_posts(params,current_user)ifAUTHORIZED_USERS.include?(current_user)# ...elseraiseBlueFactory::AuthorizationError,"You shall not pass!"endendend
Please note that thecurrent_user
may be nil - this will happen if the authentication header is not set at all. Since thebsky.app website is now open to the public and can be accessed without authentication, people can also access your feeds without being logged in.
If you want the feed to only be available to logged in users (even if it's a non-personalized feed), simply raise anAuthorizationError
ifcurrent_user
is nil:
classRestrictedFeeddefget_posts(params,current_user)ifcurrent_user.nil?raiseBlueFactory::AuthorizationError,"Log in to see this feed"end# ...endend
You can use theSinatra API to do any additional configuration, like changing the server port, enabling/disabling logging and so on.
For example, you can change the port used in development with:
BlueFactory::Server.set:port,7777
You can also add additional routes, e.g. to make a redirect or print something on the root URL:
BlueFactory::Server.get'/'doredirect'https://github.com/mackuba/blue_factory'end
When your feed server is ready and deployed to the production server, you can use the includedbluesky:publish
Rake task to upload the feed configuration to the Bluesky network. To do that, add this line to yourRakefile
:
require'blue_factory/rake'
You also need to load yourBlueFactory
configuration and your feed classes here, so it's recommended that you extract this configuration code to some kind of init file that can be included in theRakefile
,config.ru
and elsewhere if needed.
To publish the feed, you will need to provide some additional info about the feed, like its public name, through a few more methods in the feed object (the same one that responds to#get_posts
):
display_name
(required) - the publicly visible name of your feed, e.g. "WWDC 23" (should be something short)description
(optional) - a longer (~1-2 lines) description of what the feed does, displayed on the feed page as the "bio"avatar_file
(optional) - path to an avatar image from the project's root (PNG or JPG)
When you're ready, run the rake task passing the feed key (you will be asked for the uploader account's password):
bundle exec rake bluesky:publish KEY=wwdc
Copyright © 2023 Kuba Suder (@mackuba.eu).
The code is available under the terms of thezlib license (permissive, similar to MIT).
Bug reports and pull requests are welcome 😎
About
A simple Ruby server using Sinatra that serves Bluesky custom feeds