this one is a bit technical! if you’re only looking into getting the Stream Deck plugin to work, refer to the Stream Deck guide.

if you’re looking into writing your own integration for veadotube, you can use the local websocket server hosted by veado.

finding the server

if you don’t have the server address, and would rather see the list of open veadotube instances and their respective websocket addresses (if any), check inside the instances folder (refer to the data folder docs for that); said folder won’t change even if the user sets a custom save folder, so you can rely on that.

inside the folder, each file represents a different instance. the file name is the instance id, which can be parsed into three segments separated by dashes:

• instance type, which should be mini for veadotube mini, live for veadotube live, editor for veadotube editor;
• launch timestamp, hex number, always 16 characters;
• process id, hex number, always 8 characters.

only the instance type should be useful for you, depending on which program type you’re targeting! the other segments are for differentiating between instances and ensuring each instance has an unique id.

the file contents represent a JSON object, with the following keys:

• time: unix timestamp;
• name: display name for the instance;
• server: the websocket address.

you should ignore instances with a unix timestamp that’s too old – internally we use 10 seconds as the time limit. instances should clean their instance files before leaving, and new instances should be able to clean old instance files automatically too :]

bleat can is a reference implementation of that!

connecting to the server

let’s say you’re hosting at 127.0.0.1:2424. in order to connect to it, you should be using some sort of websocket client, obviously; the address you’re gonna try and connect would be like ws://127.0.0.1:2424?n=Name, where Name would be the display name of your client :]

channels and messages

all messages are prefixed with an id that represents which channel this message is being sent through, so for example a message that comes from or goes to the nodes channel would look like nodes:{"event":"list"}.

nodes

the nodes channel is where websocket nodes in the node system are exposed. to list all available nodes:

{
	"event": "list"
}

which gets you something like this:

{
	"event": "list",
	"entries": [
		{ "type": <node type>, "id": <node id>, "name": <node display name> },
		{ "type": <node type>, "id": <node id>, "name": <node display name> },
		...
	]
}

in mini, the only exposed node is a stateEvents node with the mini id, which lets you control the state stack – you can assume that and not rely on receiving a list event.

to send payload data to a node, you’d send the following:

{
	"event": "payload",
	"type": "stateEvents",
	"id": <node id>,
	"payload": <payload data>
}

you’d be receiving, then, more payload like so:

{
	"event": "payload",
	"type": "stateEvents",
	"id": <node id>,
	"name": <node display name>,
	"payload": <payload object>
}

stateEvents payloads

{ "event": "list" }

{
	"event": "list",
	"states": [
		{ "id": <state id>, "name": <state display name> },
		{ "id": <state id>, "name": <state display name> },
		...
	]
}

{ "event": "peek" }

{ "event": "listen", token: <unique id for the listener> }

{ "event": "unlisten", token: <unique id for the listener> }

{ "event": "set", "state": <state id> }

{ "event": "push", "state": <state id> }

{ "event": "pop", "state": <state id> }

{
	"event": "peek",
	"state": <state id>
}

{ "event": "thumb", "state": <state id> }

{
	"event": "thumb",
	"state": <state id>,
	"width": <image width>,
	"height": <image height>,
	"png": <base64 encoded image data>
}