Schedule C: General Platform Operating Procedures 

  1. The HAT

    1. Exposure and Functional Levels of HAT Provisioning 

The HAT has 4 levels of exposure to the outside world and correspondingly, have 4 levels of functionality 

1.1.1 HAT Level 0, zero exposure/functionality 

  • HAT content – fully private

  • No access by any service (even if the HAT is down, no one will know unless the HAT owner informs their provider)

HAT data can be viewed only by the HAT owner through their own (self created) HAT dashboard. 

1.1.2 HAT Level 1, minimal exposure/functionality 

  • HAT content – fully private

  • Access only by HAT owner through HPP Dashboard (HPD) certified by the HAT Community Foundation)

  • Permission for HATDeX to report HAT metadata to the HAT ecosystem statistics 

HAT data can only be viewed by the HAT owner through a certified HPP Dashboard (HPD). There are no dataplugs installed except the HPD plug and there are no data debits. 

1.1.3 HAT Level 2, low exposure/functionality 

  • HAT content – fully private

  • Access only by HAT owner through HPP Dashboard (HPD) certified by the HAT Community Foundation)

  • Permission for HATDEX to report HAT metadata to the HAT ecosystem statistics 

  • Permission for HATDEX to perform data concierge services to bring HAT owner’s personal data into HAT (HATDEX has no access to the content of the data)

HAT data can only be viewed by the HAT owner through a certified HPP Dashboard (HPD) AND the HAT owner has installed third party data plugs to bring data into their HAT e.g. FB dataplug, Fitbit dataplug. In installing the data plugs, the HAT owner agrees to HATDeX as data concierge to bring data into the HAT.

1.1.4 HAT Level 3, medium exposure/functionality 

  • HAT content – fully private

  • Access only by HAT owner through HPP Dashboard (HPD) certified by the HAT Community Foundation)

  • Permission for HATDEX to report HAT metadata to the HAT ecosystem statistics 

  • Permission for HATDEX to perform data concierge services to bring HAT owner’s personal data into HAT (HATDEX has no access to the content of the data)

  • Permission for HATDEX to perform data exchange services to push data out and pull data into the HAT as per HAT owner’s instructions

HAT data can only be viewed by the HAT owner through a certified HPP Dashboard (HPD) AND 

  1. The HAT owner has installed third party data plugs to bring data into their HAT e.g. FB dataplug, Fitbit dataplug 

  2. The HAT owner enables data offers, data debits or HAT2HAT messaging  and appoints HATDeX to perform data exchange services

1.1.5 HAT Level 4, high exposure/functionality

  • HAT Content – partially private 

  • Access only by HAT owner through HPP Dashboard (HPD) certified by the HAT Community Foundation)

  • Permission for HATDEX to report HAT metadata to the HAT ecosystem statistics 

  • Permission for HATDEX to perform data concierge services to bring HAT owner’s personal data into HAT (HATDEX has no access to the content of the data)

  • Permission for HATDEX to perform data exchange services to push data out and pull data into the HAT as per HAT owner’s instructions

  • HAT owner has agreed to exchange a bundle of data through a data debit

HAT data can only be viewed by the HAT owner through a certified HPP Dashboard (HPD) AND

  1. The HAT owner has installed third party data plugs to bring data into their HAT e.g. FB dataplug, Fitbit dataplug AND

  2. The HAT owner enables data offers or HAT2HAT messaging – the HAT owner allows and agrees for HATDEX to act as data exchange concierge with HAT-enabled organizations

  3. The HAT owner agrees to a contract to exchange a bundle of HAT data for his/her own benefit 

    1. Declaration of HAT levels for HAT provisioning

1.2.1 All HAT Platform Providers must provide HATs with information on their HAT levels in the settings of their dashboard, together with an explanation (or a link to the explanation) of HAT levels.

It is a business decision on the part of HAT providers if they allow users to reduce HAT exposure/functionality levels. HAT Providers do not have to provide HATs at all E/F levels. For example, HAT providers that takes data in exchange for HATs (through a data debit) is immediately only provisioning level 4 HATs.

1.2.2 Certified near-HAT applications could provide HAT functional levels 4.xx based on data debits created by HAT owners. HAT providers can opt to purchase the service (this is not mandatory).

2.0 Certified HPP Dashboard (HPDs)

2.1 All HAT providers must provide a certified HPP Dashboard (HPD), accessible from the HAT owner's PHATA (personal HAT address) URL i.e. Yourname.hubofallthings.net or yourname.savy.io.  If an application just need a subset of data for its service, they can choose to buy HATs off another provider.

Rationale:

For consistency in the understanding of HAT Providers across the ecosystem, and to reinforce the HAT ownership message

2.2 All HPDs must have a mechanism to show all the data that the HAT owner has brought into the HAT, back to the user, if the data plug is available on the HPD.

2.3 All HPDs must provide a way to receive system level notifications through the HPD interface

2.4 HATDeX provides the generic HPD for all HAT Providers as open sourced Mozilla license on Github. https://github.com/Hub-of-all-Things/Rumpel 

3.0 The DEX

What DEX does for HATs:

1. Data Plugs for inbound data are enabled via DEX

2. Data Debits for outbound data are created via DEX

3. Information about available data is provided by DEX

4. All certified and recognised HATs, apps, and plugs are registered on DEX and are interoperable only if they are registered on DEX.

Data Plugs

Data Plugs are independent services running on infrastructure separate from either HATs or DEX. Individual HATs, on the other hand, are also independent and self-contained systems that need to ensure security and integrity of individual’s data. This mitigates the risk of Denial of Service attacks by overloading individual’s HAT with fake data and of having adversary actors use the network for illicit data storage. Furthermore, HATs need to learn of new DataPlugs becoming available for their owners well after the initial creation of the HAT. It is therefore necessary to have an authority in the ecosystem which:

- Lists all verified DataPlugs, providing a trusted list of DataPlug information available across the entire network

- Specifies what data a given plug is allowed to send to the HAT and where it can be stored, e.g. to avoid a rogue plug to insert fake data into another source’s “namespace”

- Facilitates DataPlug setup - sets up the requested plug’s credentials on a HAT with the correct permissions indicated, thus enabling the plug to send data to a HAT. Without this step, unregistered DataPlugs can not arbitrarily start sending data to HATs

Data Debits

As Data Debits are the primary mechanism of retrieving data from a HAT, HATs only accept Data Debit requests from a small number of verified actors. It ensures that requests come from verified Data Acquirers, hence controlling the volume of requests the owner may need to review and preventing creation of those impersonating other entities.

DEX also monitors Data Debit status to simplify the process of legitimate exchanges: HATs call on DEX APIs to report Data Debit statistics and status changes. When a new request is created, its approval happens asynchronously and outside the control of the DEX (i.e. HAT owner must approve it themselves). Data Acquirer can therefore list all HATs that have the offer enabled instead of repeatedly attempting to collect data from every hat, hence simplifying the process as well as reducing the load on HAT infrastructure.

Information about data available

HATs report metadata statistics about incoming data to DEX, which in turn makes the statistics available to other members of the network without compromising individual’s privacy. Such statistics in aggregate help platform providers and data acquirers make decisions about what data could be used, the volume of such data available, and human-readable descriptions for integrating with data selection and approval interfaces. Such reporting in aggregate also reduces the load on HAT infrastructure while allowing for detaile monitoring of the different data points stored.

3.1 Account creation and management

All HAT providers must have an account on the DEX for the purposes of

1. Tagging their HATs with vendor/HAT Provider IDs (if applicable)

2. Ecosystem Notifications that impact on their HATs. 

3. Receiving notification of new applications that have been certified

4. Inform DEX of any errant behaviour

3.2 Notifications

3.2.1 HAT Providers must relay system level notification to HAT owner(s) from HATDeX within [xx secs]. This is mandatory, particularly if there is a breach.

3.2.2 HAT Providers must inform HATDeX on any system level issues or any breaches

4.0 HAT Applications

4.1 Rating Scheme

All HAT Applications that use HAT data are rated and their ratings must be explicitly clear to HAT owners. Please see documentation on HAT Application Rating Scheme.

4.2 The following specifies the different types of applications that interact with the HAT App and their specification 

  • Type of an app - defines the type of an application. The type of application would change how it is presented to the HAT owners and how it is set up.

    • Application types (+platform iOS, Android or web). These are:

      • DataPlug, 

      • Tool

      • External App

      • Owner apps/services (HPP Dashboard)

  • Info - defines user-readable information about the app

    • Version (multiple versions can coexist to keep track of changes and prompt user to approve new requirements)

    • Name

    • Headline

    • Long description

      • markdown + richtext formatted

    • Data Preview - main data feed structure

  • Visuals - graphical elements to build the UI from, primarily images

    • Banner (background) image (different sizes?)

    • Logo

    • Screenshots (different sizes?)

  • Data Used by the application must be specified (incl. for owners apps and external apps and their specific namespaces)

    • Data moved externally? yes/no

    • Namespace(-s) app can write to

    • Limited data read? yes/no - only Owner apps (dashboards) would have unlimited data read capability

      • Namespaces app can read from OR

      • Data Debit info for data reads

  • Setup process - how does a HAT owner start using the app. This set up process has to be approved by HATDeX

    • External - completely external process, where the user is sent off to another interface to set up. App store, web, such as notables app or data plugs respectively

      • *tech* side note for plugs: drop plug’s own credentials, move to using owner’s limited-scope ones. Token renewal is an option, but can have HAT send a fresh token when there is relevant activity on the HAT to the plug, backend-to-backend

    • Internal - set up without leaving the app, where all controls are in the next screens

      • Onboarding steps (Same as SHE enabling in existing designs - a few onboarding steps with simple heading, illustration, text)

      • Controls knobs managing when does the application run

        • *tech* side note: do a tickle on updating settings to make the app update itself

    • In both cases - “Data Used” needs an explicit approval step


  • Status check process - how does the HAT tell if the app is “setup”

    • Simple HAT-side setting check + version compatibility check, e.g. “needs updating” if data debit requirements have changed. Also include time last data recorded from tool

    • External address ping for status information (e.g. checking plugs if they can still talk to the source)

Specific examples:

Facebook Plug in the above would be of type “DataPlug” and have version, name, textual description information as currently, potentially with no screenshots. Data Preview would have two sections (feed + static) and include sample data from Leila Trilby. If the user is connected, “Data Preview” would be named “Data” and show user’s own info. Data Used by application would be set to “None” for reading and “facebook” for writing. Set up process - external and status check process external as well as simple enabled/disabled status check. The entity (person or organisation) that provides this is a data Plug Provider and data giver.

Notables would be of type “Application” with platform set to iOS (currently) and list information as per designed example. Data used by application would be set to be taken externally, and able to read/write notables from rumpel namespace AND have a data debit definition for the backing service. When the user logs into the Notables app, the app is responsible to pass on the user’s token to its backend to use for data debit value retrieval. Setup process would again be “External” (via app store) and would only a simple check within the HAT (enabled/disabled). The entity (person or organisation) that provides this app is a data acquirer and data giver

Weather would be of type “Tool” and list information as per designed example. Data Used would be set to be taken externally and able to write into “weather” namespace and read according to a data debit (calendar only? only calendar locations and time?). Setup is internal, explaining what the app does with onboarding steps and providing a choice on when to provide weather updates (e.g. 7 am every morning). Data Debit approval should be the last step after “onboarding” or part of the tweaking screen. The entity (person or organisation) that provides this tool is a data acquirer, tool provider and data giver.

MadHATTERS would be almost identical to weather, but without data reading ability, which should be reflected in the interface (as “safe”). Setup with onboarding also internal, with settings to tweak for when they want to have the updates. The entity (person or organisation) that provides this tool is a data acquirer, tool provider and data giver

Ads and other Content - very similar as well, but would depend on whether ad-matching is done HAT-side or outside (changing the data requirements section. Setup internal, with more knobs to tweak for when they would like to see ads, how many, what kind, etc. The entity (person or organisation) that provides this tool is a data acquirer, tool provider and data giver

Rumpel as a owner service/app. Setup would be “external”, however with a warning before pushing the user off to the external flow that it has full access to HAT, etc. Naturally Data Access would be “all” and status check would be a simple record HAT-side for enabled/disabled. The entity (person or organisation) that provides this is a data acquirer and data giver

5.0 HATStore

5.1 All live HATs, tools, apps and plugs must be listed on HATStore



Irene Ng