Service Hubs

[sanderpick]

Service hubs in a thread network.

• Motivation
• Services
  • Web2 Login Accounts
  • Linked Identities
  • Dapp Building
  • Data Access
  • Data Bridging
  • Usage Billing
    • Stripe
    • Filecoin

Motivation

A hub provides services to the network that make developing dapps and accessing data easier for users. These services are advertised by the host peer, as discussed in the Thread DID discussion.

Textile's current hub builds on top of Threads, Buckets and Powergate, but does not yet expose them in this way. The goal of this discussion is to shed some light on this thinking and figure out which (if any) of the services below are useful to the community while we refactor the current hub.

Building off of the Service-enabled Network section of the Thread DID discussion, we can think of a hub as a hub of services.

Services

Have thoughts about these services? Let us know!

Web2 Login Accounts

To use a hub, users create a traditional login account via password, OAuth, etc. Users can also create organizations to collaborate with other accounts. Textile is evaluating using DID-enabled Magic links to facilitate its hub accounts.

Linked Identities

One of the main goals of a hub is to make accessing the thread network very easy. This boils down to linking normal login accounts with an identity DID or DIDs. This can be done over an API or directly in a hub dashboard, where validation is done locally.

Dapp Building

There's no distinction between users and developers on the network. However, a hub can provide a good UX for getting developers started. For example, any real app like Slack or Notion needs access to structured metadata specific to the app for features like search or content discovery. The hub dashboard can provide a developer-tailored UI for designing and updating metadata schemas used in their project.

Data Access

One of the primary functions of a hub is to let users access data controlled by their account's linked DIDs. For example, data created by apps/projects on behalf of a user can be visually explored in a hub, downloaded, etc.

Data Bridging

In addition to exploring their data, users can create bridges to external services or endpoints:

• Setup web-hooks and alerts.
• Link custom domains to buckets and thread heads.
• Create bucket Filecoin archives using linked wallet (see Filecoin Wallets).
  • One-off archives
  • Scheduled archives, i.e., backups
• Create thread Filecoin anchoring using linked wallet (see Filecoin Wallets).
  • One-off anchors
  • Scheduled anchors, i.e., backups

Usage Billing

While anybody can host a peer on the network, doing so isn't always practical or even desired. In the same way that using IPFS often involves pinning services, a hub can provide a thread peer and buckets API (including a pinning API) to the network on a pay-as-you go basis with a reasonable free quota. Network usage can be broken down into the following areas:

• Thread hosting
• Bucket hosting
  • Stored data
  • IPNS mangement
• Network egress

Stripe

A hub may enable usage billing via a traditional payment gateway like Stipe.

Filecoin

Users can fund a Filecoin address to be used for usage billing. Ideally, crypto based usage billing is native to the network in a way that removes the need for a hub specific service. In other words, any peer should be able to accept Filecoin for usage billing, which should incentivize users and even Filecoin miners to run their own peers.