@Aljoscha

The createHistoryStream function is defined in secure-scuttlebutt/indexes/clock.js. It is added to a db object in secure-scuttlebutt/index.js along with other functions. In scuttlebot/index.js, one of those db objects is returned from the secure-scuttlebutt/create.js constructor into a variable, ssb. The init function in scuttlebot/index.js returns an object with methods, including passing through a few ssb methods, some wrapped with a validation function. Those methods become top-level RPC methods for that scuttlebot instance. Also in that file there is a permissions object adjacent to the init function, which allows the anonymous permission class (i.e. anyone) to call the createHistoryStream method.

You can define a #sbot RPC method by editing scuttlebot/index.js, or by adding it in a plugin. The scuttlebot module (with main function in scuttlebot/index.js) returns a constructor function createSbot, which has a use function which you can call with a plugin object to make the constructor load that plugin object. (The use function is defined in secret-stack/api.js). The scuttlebot (sbot) command is scuttlebot/bin.js and you can see the plugins loaded there with all the .use() functions called on the createSbot function. Scuttlebot plugins are loaded similarly in patchwork/server-process.js, patchbay/background-process.js, talenet/sbot.js, and scuttle-shell/server.js.

There is also a way to load plugins without editing the JS files that call createSbot. scuttlebot/bin.js and scuttle-shell/server.js will load the plugin scuttlebot/plugins/plugins.js, which then loads additional "userland" plugins, from ~/.ssb/node_modules by name according to the plugins scuttlebot config object. scuttle-shell also loads additional plugins from paths specified in a scuttleshell.json file.

By following the code for what gets loaded by the createSbot.use function, you can see how plugins are structured. A plugin is an object with an init function that gets called with scuttlebot instance and ssb-config instance, and returns an object with RPC methods (which may also get called locally by scuttlebot or other plugins). As well as the init function, the plugin has a manifest property that defines the muxrpc type of what methods the plugin defines (as returned by the init function. There can also be a permissions object to help specify which peers can call the plugin's methods. The plugin object also has a name property, which is used to namespace the RPC methods. (so gossip.connect is the connect function from the gossip plugin). If no name is given, the plugin's methods are loaded as top-level methods - but userland plugins are not allowed to do that. The plugin object also has a version property which is required for userland plugins, but I have not seen it used anywhere.