Architecture Overview

The Natster architecture relies heavily on NATS decentralized accounts as security boundaries. Each user enables Natster within their Synadia Cloud account. This creates a few automatic subject imports for things like the synadiahub catalog and the Natster global service.

The following diagram provides a layout showing how various components interact with each other. Below that there is an in-depth explanation of each component.

block-beta
  columns 1
  block
    block        
        columns 1
        global["Natster Global Account"]
        globalsvc

    end
    space
    block
        columns 1
        synadiahub["Synadia Hub Account"]
        hubservice["synadiahub"]
    end
    space
    block
        columns 1
        natsterio["Natster.io Site Account"]
    end
  end
  space
  block
    columns 1
    account1["User Account 1"]
    block
        catalog1["myvideos"]
        catalog2["thatvacation"]
    end    
  end
  space
  block
    columns 1
    account2["User Account 2"]
    block
        catalog3["influencervids"]
    end
  end

  globalsvc -- "service" --> account1
  globalsvc -- "service" --> account2
  globalsvc --> natsterio
  hubservice --> account1
  hubservice --> account2
  catalog1 -- "service/media" --> account2
  catalog3 -- "service/media" --> account1  

  style globalsvc stroke:#064d00,stroke-width:2px,stroke-dasharray: 5 5
  style hubservice stroke:#064d00,stroke-width:2px,stroke-dasharray: 5 5
  style catalog1 stroke:#064d00,stroke-width:2px,stroke-dasharray: 5 5
  style catalog2 stroke:#064d00,stroke-width:2px,stroke-dasharray: 5 5
  style catalog3 stroke:#064d00,stroke-width:2px,stroke-dasharray: 5 5  

The Natster global account is just a regular Synadia Hub account. It has no special privileges and doesn’t hold a position of any importance within Synadia. It is literally just an account we created within a Synadia Cloud team. That’s right: the key lynchpin to this application is running inside an unprivileged account. This means that any application you want to build on top of NATS and Synadia Cloud can work the same way.

The Natster global account has the following imports and exports:

• natster_global - A service export on the subject *.natster.global.>
• global_events - A feed export on the subject *.natster.global-events.*

We’ve split the subjects up into two logical roles. The natster_global export exposes a service so that clients can make NATS requests. The global_events export is a feed designed for users to subscribe to. There’s no impact on whether you do or don’t subscribe to this. The Natster.IO website uses this to help keep the interface up to date in real-time.

The Natster global service is just a Go binary that is running inside nex¹. It awaits requests on a well-known set of subjects forming the global service API.

The global service does not manage any of your sensitive information other than holding onto the last personal access token you used so that it can make Synadia Cloud API requests on your behalf. We don’t want any personal information and nearly everything stored are just reference keys and statistics to power our dashboard.

Your catalog contents are never queried, stored, or cached by this service.

Just like the global service account, the Synadia Hub account is a completely unprivileged user account with no special abilities or security clearances. It is an account just like one you could create for your applications that you build on NATS.

Inside this account there is a NATS user. Running in our cloud infrastructure is a catalog service serving the synadia hub catalog. This catalog is just like anyone else’s catalog, except that we have a bunch of interesting content in this catalog about NATS and Synadia Cloud.

It has the usual exports for a user account:

• natster_catalog - A single export used by all sharing clients
• natster_media - A stream on which encrypted and chunked data is published to valid consumers

What’s interesting about the Natster.IO website is that it communicates with NGS and Synadia Cloud as you. Just like all our other components, the Natster website has no special privileges². When you log into the website, it pulls your Natster context from a previous context binding and uses that to log in.

The website is then really just a fancy version of your CLI, but it’s running on a public endpoint, accessible anywhere, without compromising security or performance. Natster.IO subscribes to the natster.global-events.* and natster.local-events.* subjects to keep the user interface updated in realtime.

As we’ve mentioned, all of Natster is made up of user accounts. Aside from the well-known accounts like Synadia Hub and Natster Global, every user can configure an account to use Natster by running the init command from the Natster CLI.

These accounts are unprivileged within NGS and can securely share and consume services from other NGS accounts without requiring central facilitation.

When a user runs natster catalog serve on one of their local catalogs, it starts a service that utilizes 2 exports total, as well as 2 imports per imported media catalog.³

• natster_catalog - A single export used by all sharing clients
• natster_media - A stream on which encrypted and chunked data is published to valid consumers
• natster_{catalog} - A service-type import used for communicating directly with a shared catalog
• natster_{catalog}_media - A stream-type import used for capturing encrypted chunks of data requested via the catalog service.