Schedule C: General Platform Operating Procedures

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

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

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

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

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)

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

Adsand 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