4 ms·

I still wish these guys all the best, but if you want to start doing 3rd party like this then everything will eventually devolve like it did for the normal web.

I still wish these guys all the best, but if you want to start doing 3rd party like this then everything will eventually devolve like it did for the normal web. We do need a new web and way of moving information, but once you start directly connecting to servers they need to know who you are.

chatmasta 8y ago
Firefox is in the early phase of implementing support for non-HTTP protocols, starting with Tor. My understanding (from reading some Mozilla comments here maybe?) is that their goal is to make this pluggable so that eventually Firefox can support all kinds of non-standard transports, including p2p ones like dat:// We’re not there yet, but Mozilla is making a very positive step in that direction, and hopefully other browser vendors will follow. If I were creating a new protocol, I would be doing it now, to “skate where the puck is going” as they say.
- wesleytodd 8y ago
  I think the really interesting things here are more than just "support new p2p transports/protocols". The things Beaker is doing around changing the way we author the web are the real important pieces, and finding the "middle ground" or transition path is one of the keys to success. So, to answer the OP as well, supporting loading assets from traditional servers is pretty much a requirement for authors I think.
pfraze 8y ago
I don’t hold this binary view that a “decentralized Web” has to avoid certain technologies. I believe we should aim to use peer-to-peer systems where it’s impactful and practical, and in the rare case you do need a third-party server, there are things you can do to limit your dependence and make them easy to reconfigure. That’s our approach with Beaker. We use peer-to-peer systems as much as possible, and then plug in servers as minimally as possible.
- 3pt14159 8y ago
  I upvoted you and wish you all the best, but the core problem I see with this is that it makes it hard to make policy around. If I'm making a new system or setting policy for a government or other high-security minded client (like a political campaign, military contractor, activist group, or private intelligence corp) I need off the shelf stuff with zero known attack surface OR I need to individual vet every single offering within that protocol suite. This is why you can email members that work for The Government of Ontario, but they won't click on links to non-whitelisted places. The attack surface when clicking a link is fucking huuuuuge (pdf 0days anyone?), while the attack surface for loading an email is much smaller. There are a ton of interesting web-replacements that hackers are playing around with right now, but the one that wins for the next web is the one that lets stupid people do whatever they want without worrying. In my opinion, 3rd party means worrying, and in an ideal world it would go away. The irony of this whole thing is that I'm actively arguing against my own long-term interests. A structural change of the kind I advocate for would dramatically reduce the profitability of being in either data science or cybersecurity; both fields I have a foot in. But I don't care. Securing the flow of information between people is too important to humanity's long term survival.
  - pfraze 8y ago
    Yeah that's an interesting perspective. There are a lot of security issues that come into play when we start toying with how the Web platform works, and I'm somewhat curious whether all Websites should have a sort of "uninstalled" versus "installed" mode, where the uninstalled mode is basically able to do nothing. Then users have to go through an "install" flow to enable the riskier APIs. I think one other area that the Web hasn't tapped into enough is using protocol/scheme identifiers to introduce strong guarantees to URLs. You can compose schemes with a '+', so I think if you wanted an "on click guarantee" that a site is going to have certain security properties, you might try something like: http+safe://.../ dat+safe://.../ And then the site would load in a "safe mode" which, like the "uninstalled" mode, is extremely limited in what it can do.
- deleted 8y ago
  [deleted]
xellisx 8y ago
This is the whole point of 'Serverless', everything 3rd party!
- wesleytodd 8y ago
  I think you are missing the point here? Everyone is a server is pretty much the opposite of "serverless". The article is just illustrating the migration path from traditional web assets from centralized servers and how you can use them in the distributed web. A real life use case would be something like: You want to build a financial tracking app in the distributed web. But your bank is the central source for your data. With the method shown in the article you could request the api endpoint from bank.com inside your p2p/Beaker app then load that data into local storage/a dat archive/memory and use it to track your data. Think mint but without giving your bank credentials to a 3rd party.
  - xellisx 8y ago
    The name 'Serverless' really doesn't explain the concept. Basically it means you dont have to worry management of servers, and you only do low effort work by out sourcing most of your logic (authentication, db, etc) to 3rd party APIs and vendors.

chatmasta 8y ago

Firefox is in the early phase of implementing support for non-HTTP protocols, starting with Tor. My understanding (from reading some Mozilla comments here maybe?) is that their goal is to make this pluggable so that eventually Firefox can support all kinds of non-standard transports, including p2p ones like dat:// We’re not there yet, but Mozilla is making a very positive step in that direction, and hopefully other browser vendors will follow. If I were creating a new protocol, I would be doing it now, to “skate where the puck is going” as they say.

wesleytodd 8y ago
I think the really interesting things here are more than just "support new p2p transports/protocols". The things Beaker is doing around changing the way we author the web are the real important pieces, and finding the "middle ground" or transition path is one of the keys to success. So, to answer the OP as well, supporting loading assets from traditional servers is pretty much a requirement for authors I think.

pfraze 8y ago

I don’t hold this binary view that a “decentralized Web” has to avoid certain technologies. I believe we should aim to use peer-to-peer systems where it’s impactful and practical, and in the rare case you do need a third-party server, there are things you can do to limit your dependence and make them easy to reconfigure. That’s our approach with Beaker. We use peer-to-peer systems as much as possible, and then plug in servers as minimally as possible.

3pt14159 8y ago
I upvoted you and wish you all the best, but the core problem I see with this is that it makes it hard to make policy around. If I'm making a new system or setting policy for a government or other high-security minded client (like a political campaign, military contractor, activist group, or private intelligence corp) I need off the shelf stuff with zero known attack surface OR I need to individual vet every single offering within that protocol suite. This is why you can email members that work for The Government of Ontario, but they won't click on links to non-whitelisted places. The attack surface when clicking a link is fucking huuuuuge (pdf 0days anyone?), while the attack surface for loading an email is much smaller. There are a ton of interesting web-replacements that hackers are playing around with right now, but the one that wins for the next web is the one that lets stupid people do whatever they want without worrying. In my opinion, 3rd party means worrying, and in an ideal world it would go away. The irony of this whole thing is that I'm actively arguing against my own long-term interests. A structural change of the kind I advocate for would dramatically reduce the profitability of being in either data science or cybersecurity; both fields I have a foot in. But I don't care. Securing the flow of information between people is too important to humanity's long term survival.
- pfraze 8y ago
  Yeah that's an interesting perspective. There are a lot of security issues that come into play when we start toying with how the Web platform works, and I'm somewhat curious whether all Websites should have a sort of "uninstalled" versus "installed" mode, where the uninstalled mode is basically able to do nothing. Then users have to go through an "install" flow to enable the riskier APIs. I think one other area that the Web hasn't tapped into enough is using protocol/scheme identifiers to introduce strong guarantees to URLs. You can compose schemes with a '+', so I think if you wanted an "on click guarantee" that a site is going to have certain security properties, you might try something like: http+safe://.../ dat+safe://.../ And then the site would load in a "safe mode" which, like the "uninstalled" mode, is extremely limited in what it can do.
deleted 8y ago
[deleted]

xellisx 8y ago

This is the whole point of 'Serverless', everything 3rd party!

wesleytodd 8y ago
I think you are missing the point here? Everyone is a server is pretty much the opposite of "serverless". The article is just illustrating the migration path from traditional web assets from centralized servers and how you can use them in the distributed web. A real life use case would be something like: You want to build a financial tracking app in the distributed web. But your bank is the central source for your data. With the method shown in the article you could request the api endpoint from bank.com inside your p2p/Beaker app then load that data into local storage/a dat archive/memory and use it to track your data. Think mint but without giving your bank credentials to a 3rd party.
- xellisx 8y ago
  The name 'Serverless' really doesn't explain the concept. Basically it means you dont have to worry management of servers, and you only do low effort work by out sourcing most of your logic (authentication, db, etc) to 3rd party APIs and vendors.