Open Questions for Skynet Browsing

I want to create a thread to discuss the open issues that we have associated with web technology and browsing Skynet securely.

The first challenge relates to verifying content that is pulled from portals. Everything you request from a portal either has a hash or a pubkey attached, so in theory the portal should be able to prove faithful retrieval of the data. But to verify the proof, we need a browser that knows to check for the proof. It’s a bit like SSL, except instead of verifying a cert it’s verifying a skylink download or a SkyDB lookup.

The second challenge relates to cross app communication. Cross app communication is valuable because sometimes you want a piece of trustworthy code to manage what types of access other applications have to your data. The biggest example of this on Skynet today is SkyID. SkyID is priveledged code that can see all of your data, and can also control which pieces of your data are visible to other applications.

It’s reasonable to imagine that more things, like social graphs or user file storage, will need this type of cross-app communication in the future. Currently we do cross app communication by opening a brand new window for the new app, but if there start to be too many layers of communication the user may end up in a cascade of opening and closing windows when using certain apps. A lot of the times no input or interaction is needed from the user, the only reason a new window is being popped up is to make an API call to an application that has access to the user’s seed.

It’s possible that the traditional web stack already has some way to do secure communication between webapps without needing to pop open a new window for the user, but if it is possible we haven’t figured it out yet.

The third nice-to-have would be native support for resolving sia:// links. Whether that’s a skylink or an hns link, or potentially in the future some third option, it’d be nice to be able to type ‘hackerpaste.hns’ into the url bar instead of the full ‘hackerpaste.hns.siasky.net’.

The fourth nice to have, and the last thing on my list at the moment, would be native portal configuration. Right now, users can choose what portal they want to be on by selecting what URL they type in when visiting an app, but that still leaves the issue of linking to skynet from non-skynet websites. If the web browser could detect that you are being linked to a portal like siasky, and then instead connect you to your preferred portal, things would be more decentralized overall.