Draft: HTTP Pinning Service API DEP #19
Conversation
| GET /item/:key Get information about a Dat in the account's list of pins. | ||
| Key may be the pubkey or name of the dat. | ||
| POST /item/:key Update information about a Dat in the account's list of pins. | ||
| Key may be the pubkey or name of the dat. |
There was a problem hiding this comment.
do we need to discuss the payloads of the above or just make it up as we go along?
|
I plan to specify that and each route in detail
|
|
Working implementation is available at https://github.com/beakerbrowser/homebase |
|
I put together a client module as well, no dependencies, runs automated tests against homebase: https://github.com/beakerbrowser/dat-pinning-service-client |
|
Is there a requirement for these services to have CORS headers so that they could be interacted with from within a webpage? |
|
Would we want CORS to be enabled? |
|
If CORS isn't set to Not sure if there were more caveats for the |
|
Yeah I'm not sure we want to enable web pages to do that yet. Users would have to give their username/password to the site to do the login flow. For Beaker, I suspect we'd want to create some kind of utility for managing that access. |
|
I originally wrote a big rant, but the summary is that I think that nudging people to provide CORS headers for all PSAs will enable more interesting applications. Even if you don't want to explicitly require it now, this can be changed in the future and could be enabled by hosts that want to allow it. My original rantI get the use case for beaker, but I could envision people making apps for doing similar things that could work with these services regardless of browser. If Beaker provides a great way to integrate with these services, people are less likely to go apps that implement the same thing.I could however see myself making a private app so I can manage my dats from either Beaker, Bunsen (before they integrate it), or the upcoming browser extensions. Locking these services to make them only usable to the browser runtime itself will make it harder to innovate. I agree that a pinning service that takes credentials might want to be more guarded against letting web apps use it, but I could see pinning services without credentials, or completely different (e.g. discovery) services that would be more useful if apps could do whatever they wanted with them. Explicitly specifying that only browsers will be using the DEPs will set a precedent that will stifle innovation and could lead to PSAs being used by beaker and not by third parties. |
|
That's a fair point. |
pfrazee
changed the title
|
This looks good to me for Draft status. We do usually want a "Privacy" section for standard/protocol DEPs, even if it's just a "no privacy concerns" or "this is for public/published works only" context note. |
|
Did you mean to link to archive.org instead of direct a link? It appears twice. |
|
@millette yes, that was intentional to make sure the linked target doesnt change |
Implementations: