Multiple ways to build the SAFE Network browser extension!

Development
1

As some of you already know, @frabrunelle @erick and me are behind the Montréal POD. At our first meet up, we brainstormed and decided to build a browser extension that will allow normal users to access webpages hosted on the SAFE network.

We found multiple ways to achieve that vague goal. Three were retained, and we’d like to ask you your opinion on them.

1 . Create a browser extension that would generate a config file for a request to the SAFE Network. The extension would then call an executable (that is able to send requests to the SAFE Network) and pass the config file as an extension. This is what XTTP and MeshedSites are doing.
Pros: Light extension.
Cons: Need a MaidSafe installation from the User (or at least a light version) and ask him where it resides, is more prone to slowness, we would surely need to build the executable.

2 . Create a browser extension that would redirect (in background) SAFE Network requests to a local proxy. This proxy will then treat and send the request to the SAFE Network. The proxy would need to be a full featured MaidSafe package, like what I2P does.
Pros: Really simple extension, easy to port to other browsers.
Cons: Need to install a packaged version of MaidSafe containing the local proxy. We would need the build the proxy and package it.

3 . Create a layer on top of the MaidSafe librairies in Node.js, using node-gyp to integrate the MaidSafe C++ librairies inside the layer. This layer could then be integrated in a (heavy) extension.
Pros: The layer (or Bridge, as we call it) could help other developers to start their projects, The User doesn’t need to install anything else, Easier to integrate the MaidSafe APIs.
Cons: The extension would surely be heavier than most extensions, it would also need to incorporate executables for all platforms (if I understood node-gyp correctly).

That’s about it for now! We’re eager to hear you out!

3 Likes
2

I really, really like XTTP. Big fan. And the inevitable browser extension for MaidSafe is such a cool thing.

2 Likes
3

As much as XTTP is a nice thing, it might not fit well with the internal design of MaidSafe. They both are decentralized (MeshedSites and MaidSafe) but the API principles might be very different…

4

I’d be interested in your opinions of Breach for this…

3 Likes
5

I would say do all three but start off with number 3.

2 Likes
6

Breach seems pretty nice! From a developer point of view, build an all new browser is a fun thing and a great project! But to gain critical mass, we need to get users on the network and typically, users like to stick to their browser (although Chrome is an exception, it used a lot of pub). I don’t shelve the idea and I will forward it to my colleagues!

Correct me if i’m wrong, but i think that for users, having and extension is easier, isn’t it?

1 Like
7

I think David Irvine indicated that as far as browsing SAFE he envisaged an extension first, followed by a native browser and I think, but am not entirely sure…a native OS

This was because of speed to market I believe.

So Breach may be suited to being a native SAFE browser…I believe it was suited because of JavaScript being a good fit.

So your right, an extension was first on the road map and like you say…people like familiarity.

3 Likes
8

I like option 3 as it seems it might be the most end-user friendly though not if bandwidth and device capabilities are limited.

3 Likes
9

I’m sure this subject has be tackled, but I got an idea for the (obvious) problem or hostnames and such to browse the SAFE Network. Because of the decentralized nature of the network, there is no DNS, which leads to no “safe://safenetforum.org”. What I tough to fix that problem by incorporate public shares.

Say that I put html and css files in my public shares, and given that my username on the Network is “lejacobroy”, people could go the “safe://lejacobroy” and it would just point to my public shares and display its content.
Simple, feasible and pretty!
What do you think?

4 Likes
10

Exactly as it supposed to be, good stuff. I like simplicity :smiley:

4 Likes
11

What we have not fixed and it may be nice is
safe::lejacobroy/www
safe::lejacobroy/blog
safe::lejacobroy/microblog
etc. If we did and guided people to use that then we could make navigating easier I think. (PS no need for the //, we discussed that a while back and even Tim Berners Lee reckons it was a mistake).

5 Likes
12

Thanks @dirvine this is really nice!

Thinking out loud here (this could make a new thread entirely) :
We could also rework the url completely (while being simple for normal users), something in those lines:
safe/lejacobroy/www
safe/www/lejacobroy
safe::lejacobroy/www
safe::www/lejacobroy

The www is a mark of familiarity with the old web (the World Wide Web), but it is in fact useless as it is replaced by safe:: (or something alike) !

13

It is true WWW is familiar but it may confuse new users. They need to know they are on the new internet and not on the old internet. Once they log into the SAFE Network, they are in a self encrypted decentralized colony of vaults. I believe this network is capable of bringing almost any feature directly to the web interface.

Here’s how…

  1. Prefix " SAFE: " into the address bar. They only type the website address. This will transition people into seeing SAFE as part of the new internet address without remembering to type it. I’m a lazy typist.

  2. Upon login, an address domain should be reserved on the SAFE Network based on the login name or public ID if it has not been taken. This is up for discussion.

  3. The " / " should indicate sub pages as normal.

  4. A " . " extension could point to a web APP which will activate when called from the address bar.

Example SAFE Address Structure.
SAFE:dyamanaka/home
SAFE:dyamanaka.starblog

SAFE: = Clearly indicates the browser is operating on the SAFE Network

dyamanaka = my domain address by default when my login was created on the SAFE Network.

/home = example of a customizable sub page, made public or private.

.starblog = is the name/ID of the actual APP that has been uploaded on the SAFE Network. In this case, it’s a blogging APP that allows the user to: follow, post, and like other blogs using the same APP. This could apply to any web APP: email, messenger, video, audio, etc.

I believe 1-3 are doable with #4 being most difficult.

As for a search engine, we use address submissions. If I create a new website called SAFE:dyamanaka/cookies which is my site that sells cookies. I would want people to know about it. So I would submit my address to the search engine index. The APP would then look at my website and create its own search tags for querry.

Or… search tags can be submitted by the website owner along with their website address for indexing.

Or… an advance search engine would automatically index any public webpage the minute it is browsed. The users would do the work by just surfing new sites, including their own.

There’s lots of things we can try, some are easy, some are impossible. The goal should be to create a better user experience compared to the old internet. I would really like to see it tied together in a seamless way. Because of the way the SAFE Network is structured, we have the ability to create a smorgasbord of widgets or APPS without needing any central authority. If you like my ideas, use it. If you know a better or easier way to do this, I would like to hear it.

8 Likes
14

Did you really mean :: rather than : or are you now so deep in the code you’re unable to speak Scottish too :wink:

2 Likes
15

@dyamanaka I like all those ideas a lot great stuff!

1 Like
16

Can we design it so every public site automatically goes into the search engine without having to be manually submitted?

Why repeat the mistakes of the web? Why not index it all by default?

17

Personally am not a fan of imposing too many guideline’s / requirements at the system level to one allow ease of use and second allow creativity.

Having something like “safe::public-name/” is fine since it’s fairly basic, you’re connecting to the network to some user. After that point, not really a fan of adding /blog, /www, /something-else, that’s just glitter we don’t know if it’s going to be useful later on or just a hindrance.

Just as a thought people often ask us, how would children be protected in a network like this where anyone could post anything they want. For all we know in a while a whole new set of apps could come along that can provide content that are deemed safe for children. Now how they do this “safe for children” is a whole other topic since these apps doing the filter could either be valuable or pretty much block you from seeing content they don’t want you to for their own benefit.

Now if we assume, We got an app that does filter on some agreed terms to get content only appropriate based on a criteria, I’d be completely fine in it imposing it’s own url scheme such as

child-safe::any-name

Now this app’s code can be alerted based on the child- prefix and then check if the url entered matches it’s whitelist and show content by essentially going to a safe://public-name in the background. While it’s pretty much just a forward the app’s doing, as far a user’s are concerned, this app’s helping them keep their children safe from content they don’t want them seeing.

@LeJacobRoy I think the config file/IPC route with the addon will indeed be a much quicker approach to get an extension going and be a nice first app to grow the dev base / get more support for a full fledged implementation such as with a node package.

Having a self contained solution such as a node package would indeed be the best to have, however as things start speeding up in the API project, we should have a much better idea of how feasible it is to say use one routing object among multiple clients and how extensible is that approach across the various platforms(desktop/mobile) to then have the node package evolve accordingly.

5 Likes
18

Let’s not forget that the DNS problem still holds for the username. How will they be allocated?

1 Like
19

MPID’s are unique, as it stands, if you got it when no one else did, it’s yours.

1 Like
20

So they would be assigned on a first come first serve basis? For example, the first person to grab ‘erick’ would preempt everybody else from using it, right?

Maybe the MPID could be numerical and randomly assigned from a huge space, and people would be free to give it a friendlier ‘human-readable’ name. As long as nobody would be using it, it would be unique. However, if somebody else was to use the same, the browser could disambiguate from the rest of the url. Failing to do so, it could provide enough context to choose one amongst many. This is pretty much what happens when searching someone not in your friends list on Facebook, or typing someone name on Google and then choosing a particular result.