Draft: HTTP Pinning Service API DEP

[pfrazee]

Implementations:

• Server: https://github.com/beakerbrowser/homebase
• Client: https://github.com/beakerbrowser/dat-pinning-service-client

[pfrazee]

I plan to specify that and each route in detail

[pfrazee]

I plan to specify that and each route in detail

[pfrazee]

Working implementation is available at https://github.com/beakerbrowser/homebase

[pfrazee]

Working implementation is available at https://github.com/beakerbrowser/homebase

[pfrazee]

I put together a client module as well, no dependencies, runs automated tests against homebase: https://github.com/beakerbrowser/dat-pinning-service-client

[pfrazee]

I put together a client module as well, no dependencies, runs automated tests against homebase: https://github.com/beakerbrowser/dat-pinning-service-client

[RangerMauve]

Is there a requirement for these services to have CORS headers so that they could be interacted with from within a webpage?

[RangerMauve]

Is there a requirement for these services to have CORS headers so that they could be interacted with from within a webpage?

[pfrazee]

Would we want CORS to be enabled?

[pfrazee]

Would we want CORS to be enabled?

[RangerMauve]

If CORS isn't set to * you won't be able to do POSTs in JS AFAIK.

Not sure if there were more caveats for the dat:// origin.

[RangerMauve]

If CORS isn't set to * you won't be able to do POSTs in JS AFAIK.

Not sure if there were more caveats for the dat:// origin.

[pfrazee]

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.

[pfrazee]

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.

[RangerMauve]

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 rant

I 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.

[RangerMauve]

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 rant

I 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.

[pfrazee]

That's a fair point.

[pfrazee]

That's a fair point.

[bnewbold]

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.

[bnewbold]

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.

[millette]

Did you mean to link to archive.org instead of direct a link? It appears twice.

[millette]

Did you mean to link to archive.org instead of direct a link? It appears twice.

[pfrazee]

@millette yes, that was intentional to make sure the linked target doesnt change

[pfrazee]

@millette yes, that was intentional to make sure the linked target doesnt change