Switchboard Protocol

Users observe a genesis address on any network for announcement messages from content beacons. Users then observe these beacons for content announcement or the addresses of content maps published by each beacon. These content maps contain data and locations, possibly on different networks, for all content submitted to the beacon with an optional step of processing or curation undertaken by the beacon operator. This process happens off chain, but can be recreated by any user to reveal any difference between submitted content and published content— intended or fraudulent. In this way, users can “fork” a beacon by monitoring it and publishing their own version of content maps based on its submissions.

Users can submit content to these beacons by sending a message to the beacon address as well as any fee (if required for submission or anti-spam) that contains the address of the content to publish and associated data. If the content is accepted by the beacon (or by any other users processing that beacon address) then it will be included in a content map.

Unlike consensus-based protocols, Switchboard does not have a group of peers that all arrive on a single state for the network. Instead the consensus mechanisms of each utilized network arrive on their own state and Switchboard participants observe messages across these networks to be interpreted and filtered according to the user’s preferences. There exists a total sum of all Switchboard content on any given network, but users only care about and observe the activity that is relevant and valuable to them. In this way, Switchboard acts more as a shared language that can be used by peers to communicate across any number of networks.

CONTENT

The unit of data shared on the network, a specific file (text, image, video, archive package of web files, code, application).

CONTENT NETWORK

The network that will store a piece of content. This includes a decentralized storage provider (ipfs, storj, sia, etc.) as well as any other network addressable storage location for which there is a viable storage module.

CONTENT ADDRESS

A link or address to a specific piece of content on a content network.

CONTENT MAP

A list of content addresses. These maps are published by active beacons and are the result of applying any beacon specific filtering, verification or curation to submitted content.

TRANSFOR MODULE

The interface by which a piece of content is uploaded to a content network, this could include ftp, ipfs, or any other viable transfer protocol. Storage modules are run locally by the client.

MONITORED BEACONS

A list of beacon addresses that are monitored for new content maps. When a content map is published by any beacon on the list it will be retrieved and then scanned for any new content from monitored publishers or content that matches any other filters set by the user.

MONITORED PUBLISHERS

A list of all addresses for which to retrieve content. When the client sees new content from an address on the monitored publishers list in a content map it will be retrieved and added to the local feed.

LOCAL FEED

All content retrieved from content networks, to be filtered and displayed by the client according to any local rules. 

GENESIS BEACON

The address(es) on any network used by beacons to announce themselves.

Unowned and standard across networks (to the extent possible, e.g. – 0x000...00).

‍

‍DISCOVER AND FOLLOW BEACONS

• The users watches the network's genesis beacon via a discovery module.
• The user discovers a series of content beacons as they announce themselves and chooses a subset to follow.
• The user detects a new piece of content submitted to the beacon and saves the content address
• The user downloads the file from the content address
  ‍

‍DISCOVERY MODULE

‍The interface by which networks are monitored for content messages. Discovery modules can work either as nodes in which the client is directly analyzing transactions for the integrated network to look for updates or as interfaces into third party data services, such as block explorers.

ANNOUNCEMENT INTERVAL‍

The suggested rate at which active content beacons announce themselves to the genesis beacon. The more frequent this rate the easier it is for a client to discover content beacons without the need for an active beacon to process beacon announcements.

DESIGN FEATURES‍

The protocol is a map of references that builds from a single address, can span networks, and collects at public beacon addresses.

Users can verify or process any network content or function locally and never need to rely on any other network member.

The network functions with two users and scales to the technical limits of any content or publishing network it utilizes.

The client-based processing approach provides network independence and the ability to utilize features of multiple networks while never relying on any single one.

PROTOCOL DESCRIPTION‍

The protocol is a series of references and can be used by any client to discover and interpret content. The entire network unfolds from a single address— that of the genesis beacon. This acts as the root for a content network and, from this address, the network of beacons, content and publishers should be accessible and interactive. The architecture allows for a mix of public and private beacons and networks, so, while there would likely be a single (or few competing) primary “public” networks, there would be a host of private and semi-private networks alongside it with users consuming and publishing across them. Due to the modular nature of the switchboard protocol its networks could exist on any number of base protocols, each with its own genesis beacon.

‍

ACTIVE BEACONS

• Users submit content and metadata to an active beacon.
• The beacon owner processes those submissions and applies curation, verification or filtering resulting in a content map
• The content map file is uploaded to a content network.
• The location of the content map file is published by the beacon and observed by any monitoring clients.

Since beacons process maps offline, there is always the opportunity for dishonest behavior. To address this, any client can verify a given beacon’s activity by rebuilding the activity of content map construction.

Beacon owners can set a submission fee for publication to be included with the submission message, potentially as a review fee for curation or as a deterrent for spam submissions. Since beacon owners are not technically necessary and clients should be able to perform content map processing, beacon operators should emerge when they provide enough value to warrant fees. These could include high quality curation, spam and bot filtration, content moderation and compliance or others. Or, when there is a secondary incentive, such as building a platform/audience, promotion of a client or network, or even expanding the robustness of the protocol itself.

The client acts as the “switchboard” interpreting and transferring messages between networks. The client consists of a set of three module types: storage modules (which allow users to upload and download content to and from the network); publication modules (which publish messages about content to a network and make content discoverable); and discovery modules (which learn about new content from beacons on networks.)

‍

CONTENT PUBLICATION

• A user wants to share an image using Switchboard, and uplads the file via a client.
• The client uploads the file to a File Storage Netowrk (FSN) via a storage module and saves the public address of the file.
• The user then uses a publication module within the client to announce the content to (3A) a public filesharing beacon as well as (3b) a private beacon they share with friends and family.

With these three functions– file transfer, message publication and message observation— the client software can fully utilize the protocol. 

Additionally, the client can act as a local beacon (or active beacon) and process publication messages itself. In this way the only functional difference between a beacon and a client processing locally is if the result is published to the network.

The client-based approach is appealing because local rules can be applied to display the network content in any format or configuration and then be filtered or organized according to user preferences. Further, the content publication and consumption experience is fully independent of the underlying networks, so the client can seamlessly benefit from advancements at the network level.

While content is public on the networks by design, in most cases the protocol works just as well for encrypted content. This can happen at two levels. First, the files uploaded by any user can be encrypted before upload and submission. The user would then share keys with any parties in advance, who would use them to decrypt the files after transfer via the network. Additionally, users could use unannounced beacons for private groups, and further encrypt the publication messages and data, given coordination with the beacon owner, or in the case of distributed local content map processing where each member has a key. Key sharing is an example of a service imagined to be enabled at the client or through complimentary services but not within the protocol itself.

‍

EXAMPLE CONFIGURATIONS

Bob is an avid writer. After setting up his switchboard client he enters the address of the genesis beacon on the Ethereum mainnet. The client begins processing maps with a discovery module integrated with a popular block explorer. From this stream of updates Bob discovers a series of popular content beacons. Among them an open and active community of writers in the style of Medium and a curated collection of writings, administered by a known author, updated weekly. Adding these beacons to his watchlist his client begins monitoring for content from all three. Given the active and open nature of the Medium-style content node Bob enables a set of local filters that automatically screen known bot and spam content, as well as highlighting mentions of topics of particular interest. As Bob reads the latest update from the curated writing community he realizes that he has recently completed a short story that would be well suited for submission. Using a storage module in his client he uploads the text of his work to IPFS as well as an AWS web server he shares with some friends. From here he selects both the open and curated beacons as content destinations and attaches the submission fee and a note to the transaction to the curated beacon. Once the message is published he can see the story appear in the feed for the Medium-style beacon and other users can discover, read and share his work.

In the above example the file type, curation and filtering methods can all be swapped out to create content networks of any type, including the delivery of web content/applications. Switchboard works at a low level with the idea that developers and users can build a configurable stack of functionality on top of it.

Switchboard has the potential to act as a trusted messaging or broadcast system for projects, dapps and networks. Instead of proving ownership of an off-chain Twitter account, email or site projects could send messages directly from wallets with known control. These would then be observable and directly verifiable as authentic content by watchers. Additionally beacons across multiple networks could be used to publish ownership verification messages allowing users to prove shared ownership of multiple accounts across networks in a way that’s observable and verifiable, further extending the potential utility of message publication.

USER: PUBLISH CONTENT
‍

1. A user selects a piece of content they want to distribute (image, video, text file, html bundle, etc.)
2. A user selects one or more content networks from a list of transfer modules, each of which can have multiple configurations of credentials and settings:
   - IPFS: settings + credentials
   - IFPS: Alternative Credentials (settings + credentials)
   - SIA: settings + credentials
   - AWS host / FTP / other (settings + credentials)
   - etc.
3. <optional encryption step>
4. The transfer module uploads the content to the system and upon success returns a content address that a user can share with a beacon or another user
5. Once the upload is complete the user then selects one or more beacons via a publication module on which to publish their message.

‍

PUBLISH MESSAGE STRUCTURE

• Content Owner Address
• Tags
• Is Encrypted
• File locations[x]

‍

NOTES

File location is a list of all locations where the file has been published. In this way fallback or alternative options can be provided for any file, e.g. a traditionally hosted file location may be paired with a location on a decentralized provider, and further with a locally hosted location, to provide both more performant and more resilient options for file retrieval as well as a fallback.

Content Owner could be the submitter or the address of another publisher on the network. In this way content can be linked or “reblogged” with attribution to encourage discovery.

‍

USER: BEACON DISCOVERY
 

1. A user enters the genesis beacon address into the client via a discovery module (Ethereum, Stellar, EOS, Decred, other).
2. A set of beacons is retrieved:
   (a) If the user connected to a beacon that is processing the genesis beacon then they’ll  wait for the next content map link from the address.
   (b) If the block link is not available or if the user is running fully local, then the client begins to process the genesis beacon transactions to identify beacons.
3. The beacon list is populated with discovered beacons for observation or publication.

‍

NOTES

Genesis beacon is a reference address without an owner in a network, therefore a user processing all logic locally could use it to build a list of active beacons. Otherwise a typical user might connect to a beacon that processes the genesis beacon to more efficiently retrieve the active beacons, and potentially, filtering or curation on top of basic announcement.

Beacon discovery can take place at any interval as once they are known they do not need to be re-discovered and become the source of further network content.

‍

USER: CONTENT DISCOVERY AND PROCESSING
‍

1. A user watches their monitored beacons for new content maps on a publisher network.
2. A content map is detected and downloaded from its content network via a transfer module.
3. <optional decryption here>
4. The content map is processed by a set of filters defined by the client. This could include:
   a. content from an address on the list of monitored publishers
   b. content that matches a file type or tag
   c. content recommended or rejected via a curation or filtration module
   

‍

BEACON: PROCESS AND PUBLISH CONTENT MAP
‍

1. Beacon gathers all transactions sent to its address (or its target address) during the content map interval
2. Beacon processes these transactions by filtering, verifying or curating according to its policies
3. The results are formatted into a content map and published to a content network
4. The location of the content map with the results is then published to the publisher network and sent to one of two signal addresses:
   a. its own address, for an unannounced map
   b. to the clearinghouse address, for a public map

‍

CONTENT MAP ANNOUNCEMENT

• Destination Address
• Content Map Network
• Content Map Address
• Is Encrypted
• Meta Data/Message

NOTES

File location is a list of all locations where the file has been published. In this way fallback or alternative options can be provided for any file, e.g. a traditionally hosted file location may be paired with a location on a decentralized provider, and further with a locally hosted location, to provide both more performant and more resilient options for file retrieval as well as a fallback.

Content Owner could be the submitter or the address of another publisher on the network. In this way content can be linked or “reblogged” with attribution to encourage discovery.

‍

BEACON: ANNOUNCEMENT

1. Beacon generates an announcement message
2. Beacon sends an announcement message to the genesis beacon address every announcement interval to signal liveness and update any beacon parameters

PUBLISH MESSAGE STRUCTURE

• Destination Address
• Beacon Address
• Beacon Name
• Beacon Short Description
• Beacon Long Description/Rules (content map address)
• Supported Content Types
• Accepts Encrypted