Feature Request - Scrapbook Plugins Support

[JosiasAurel]

A new architecture that will enable scrappy to support plugins created by Hack Clubbers while also exposing APIs that will enable Hack Clubbers to build their own apps for creating and viewing scrapbook posts. These plugins will be able to perform a limited number of scrappy functions and integrate with external modules.

This plugin architecture will support various use-cases such as

• Listen to scrapbook updates with a #arcade for Hack Club Arcade
• Build custom interfaces for sending scrapbook updates
• A plugin that allows you to subscribe for email/dm notifications whenever someone or something that interests you is posted in scrapbook
• A plugin that flags inappropriate content and alerts CRT
• and many more...

Here's a document that goes a little more in-depth into this proposed feature - Scrappy Plugin Architecture

Note that this is not final and may change any time.

[SkyfallWasTaken]

This would be incredibly helpful for a few projects I'm making, such as a Scrapbook to Bluesky bot, or a Scrapbook integration for the streak tracking app I'm building

[SkyfallWasTaken]

I also wonder if we could have something similar to a gateway on Discord, or a firehose on Twitter/Bluesky. Essentially:

• An API user can connect to wss://scrapbook.hackclub.com/gateway or something like that, with an optional cursor value that allows you to replay missed messages
• When a Scrapbook update happens (like a new/deleted post or streak update), a message is sent out to all connected users with a incrementing cursor value
• To send a message to the server, the client can send a JSON message with the request
• Client libraries can make this nicer to use for users

The Prisma schema does appear to have CUIDs for updates, so we can just use that for the cursor. On the server, it'd be as simple as fetching posts/reactions/whatever with an id greater than the cursor value, sending them out to the user, then connecting them to the gateway as normal.

There are a few advantages to this approach:

• People can use any language they want
  • Even without client libraries, the gateway would be simple enough that you could just use WebSocket and JSON libraries to connect
• People can do things that would be slow/expensive to run in the Scrappy codebase
• People can't slow down Scrappy or introduce security vulnerabilities (intentionally or otherwise)
• People don't have to hand over e.g. API keys
• Less code complexity in Scrappy

To prevent abuse, firehose access could be limited to people who've created a Scrappy "bot application", with preapproved scopes. The user could then opt out of an application on the settings page.

[JosiasAurel]

That's an equally interesting approach. I was originally thinking of going with a RPC type service which is also language agnostic. Which is better is something we can discuss more thoroughly once we're set on implementation.