Repost is designed to fit in alongside your serverless cloud functions (e.g. AWS lambda, Google Cloud Functions).
As your services become more complex, they will start to require to send messages to one another. You can directly call the address of another endpoint to send a message to it. But if that changes or you wish to notify more services of an event, you have to modify the publishing service as well as the receiver.
PubSub message systems (RabbitMQ, MQTT, Redis PubSub, Kafka) solve this by having a single message broker. Your publisher sends a message to the broker with a topic. Services that wish to receive the message connect to the broker and subscribe to a topic, and from then on when the broker receives a message the receiver will be informed.
This system works, but the subscriber must always be connected to the broker - which doesn't work well with serverless functions that are only running for as long as the function executes.
In Repost, your publisher still sends a message to a topic. A subscription, however, is defined as an http endpoint. When it receives a message on a topic, repost will initiate a POST request to each endpoint with the message - without the receiving endpoint needing to be aware of the source of the message. By this mechanism we say that Repost is a disconnected pubsub broker. Adding new subscriptions needs no modification to the sender, and the receivers may be serverless functions.