old notes ("certified pod providers")

I mentioned yesterday I'd once written up some stuff on this.   Here it 
is, from a July 2014 email.   The terminology is specific to that 
project; a "pod" is a single user's data server.   The first paragraph 
refers to the problem of how an app can responsibly help users sign up 
for a backend service.  ( demo of that at 
https://www.youtube.com/watch?v=z0_XaJ97rF0 )   Much of this is probably 
too low-level or weird for RTOS.

We should probably make a wiki page enumerating the various attempts in 
this space.

     -- Sandro

=====

One of my long-standing concerns has been around that dropdown box in 
cimba that lets the user pick between rww.io and data.fm.  Who gets to 
decide which services are listed there?  What are users told about each 
one, to help them decide?

Another long-standing concern has been about how we get pod providers to 
behave well.  How do we get them to implement the specs properly?  How 
do we get them to provide subdomain portability?  How do we get them to 
respect user privacy and autonomy?

Here's a proposal to address both these areas of concern.

The basic idea is that we have a notion of certification for pod 
providers.  To be a certified pod provider (CPP) you have to do certain 
things, which basically amount to behaving responsibly. There would be 
some Pod Provider Certification Authority (PPCA) which coordinates the 
certification process and publishes the list of CPPs. That list of CPPs 
(along with associated metadata) would be used to populate the widget 
applications typically use to helps users choose a new pod provider.

Nothing in the system would prevent random people from running their own 
pod, or even providing pod service to the public.  They just wouldn't 
show up on the menu for new pods, and (depending on local laws) might 
not be able to legally claim they were a CPP.  Local laws might someday 
prevent non-CPPs from offering service to the public.

The PPCA might be W3C, or it might be something else.  TBD.  There might 
be fees associated with being a CPP, and those fees could fund the 
PPCA.   The certification process might be just filling out a legally 
binding form, or it might involve some kind of interview or inspection 
process from the PPCA.

Some possible requirements for a CPP:

- all key information in machine readable form, but also legally binding
- faithfully implements some version (or versions) of the pod spec
- uses standard data-shape for TOS, pricing, which versions implemented, 
etc
- must provide 90 day notice before shutting down, changing the TOS, or 
raising prices (notice to be provided using appropriate pod messaging 
protocols, at least)
- must implement protocols (when defined) for easy service termination 
with migration elsewhere, without penalties or awkwardness
- must provide URL forwarding and subdomain portability after service 
termination for no more than 10% of the price of the service at the time 
of termination  (alternatively: must allow people to switch to a 
forwarding-only service priced at no more than 10% of their existing 
service)
- must be non-discriminatory in providing backlinks.  (in particular, we 
want vocabularies to link to their competitors, and products to link to 
sources of reviews of those products.)
- must be clear about how their infrastructure is secured; maybe require 
minimums like the credit card companies do
- participate in good faith in a review and dispute resolution system 
(eg listen when people post complaints; don't create fake complaints 
about others)
- maybe something about a patent defense pool
- revenue sharing with applications: perhaps 30% of revenue from each 
user gets given to apps that user uses, under user control and 
defaulting to some "fair" formula

That's the basic idea.   It probably seems a little early to be thinking 
about this stuff, but I think we need to make it clear before talking to 
other folks who might want to provide pod services.

Received on Friday, 4 December 2015 18:12:09 UTC