By going to the developers portal you can start building right away. Just press build on the home screen!
In your own private HAT PDA microserver! On the cloud of course...
Yes, the sandbox is built to support the full functionality available on the production network. As a result, it can be built on the sandbox network and eventually migrated to production with relative ease. One thing to bear in mind though is that the sandbox is essentially a network of distributed HAT microservers. You will still need to deploy your data plug service into own cloud infrastructure. Click here to find out more.
What we effectively call a Data Plug is something that has virtually unlimited ability to write data in, but a heavily restricted ability to read data out. So far, we have only focused on developing Data Plugs as API-to-API backend services, which take care of synchronising data between a given third party and user's HAT.
Every data plug goes into their own namespace. However, how you want to show this data back to your user is up to you. You can add as many data sources as you want but that doesn't mean you want to access it all. After the data has been preloaded and the API's are active, your app can access on demand the data they want within the HAT PDAs.
All the user authentication is done within their individual HAT PDA micro-server. It was designed like that to ensure security and decentralisation. Central authentication micro-service would become a single point of failure, obvious target for hackers and technically would give us access into the user's HAT PDA.
This is not allowable under the HAT security and permission model and not allowable under GDPR or Facebook rules. Credentials cannot be passed. We can, however, customise the screens to different look and feel, as long as it's not too different.
Yes, but we need to check that it doesn't look too different because it might be confusing. For example, if an existing hat owner goes to your app, I assume he should recognise that this app can be logged in with his hat and when he gets in, he must be able to use it since he already has Facebook data? So, if you make it too different, you need to account for how you deal with the existing hat owners
Well, it's your own Personal Data Account (microserver) on the cloud where you can store all kinds of information. Think of it as your personal digital safebox. You keep your data safe and private and only YOU can decide when and with whom to share that data with!
A user can login to websites and apps using HAT through a single sign on, but you cannot login to HAT with other logins
A HAT PDA microserver must be available in order to deposit data into it. There would be two scenarios to handle: in case the user already has a HAT it would be a simple login procedure in OAuth fashion, in case of a new user they would need to be provisioned with a new HAT PDA.
Authorising the Data Plug is done through an authentication process on a web browser. The person must authorise the pulling of his data from the data plug into his HAT PDA and agree to the write access of the plug into his HAT PDA.
Dataswift platform does not differentiate between types of data that is being stored in the HAT, so the standard pricing model applies. Writing data in is free while reading it from data plug's own namespace would cost 0.002 / API call.
The Facebook data plug continually syncs with Facebook, so the HAT is always getting data from Facebook, a sync every hour or so.
Under GDPR and the HAT permission model governed by the foundation, the user must approve the data debit and the permissions, but this can be done once at the start.