Just beginning to explore SAFE... got questions!

Beginners
1

Hello there!

I just installed the demo app + launcher on a test vm, and am up and running with a static website on the .safenet.

While there are many many questions that could be asked at this point, in order to direct further self-study, I’d like to get a better understand of the following:

  • Is anything gained by transparently proxying the launcher through Tor in terms of privacy/anonimity?

  • Why are a PIN, keyword AND password required? This is certainly unusual, what’s the reasoning behind it?

  • The docs frequently mention the mounting of a virtual drive on the OS (I’m on Linux), but at present I cannot locate any FUSE mountpoint when the launcher is up and running. Has it not been implemented yet?

  • Are there any provisions to limit access to files to groups of users, in other words, something in between “completely public” and “completely private” ?

  • I’m having a hard time imagining how to run, say, an IRC or XMPP server on .safenet. Is this sort of usage even supported?

  • Is there any place for Python, Ruby, SQL, etc, using this paradigm? Also having a really hard time conceptualizing how that’d be possible…

Looking forward for some answers!

2 Likes
2

PIN and keyword create a hash together. That’s the address of your personal file in the network (in short). To de-crypt your personal file you need the password.

Nope, SAFE is build from the ground up. It supports static websites and Javascript etc. But not the dynamic idea with a server. There are no servers on SAFE. So people have to create different solutions to create the same outcome using structured data.

4 Likes
3

Some answers…

Nope, anonymity is provided by safe as well. Having said that, the product is immature and in beta so caveat utilitor. Tor has years of vetted (and compromised yet fixed) security. Also note that Tor is anonymity by obscurity whereas maidsafe provides that and encryption.

Nope, not quite yet IIRC.

Not really. This is a hard problem and IMO would be expected to be handled by developers on top of safenet using things like shared intermediate keys or other group-based encryption.

Someone builds an abstraction. An app dev takes the IRC protocol or XMPP protocol and implements it with the backend being safenet. This is not done, the dev-facing implementation is in its infancy.

Python: yes. Ruby: yes. They are just programming languages like any other and can be used to create apps like any others. SQL: not really (IMO). This is specific to relational databases. Granted you might be able to provide a SQL abstraction on top of Safe ala Hive, CockroachDB, Cassandra CQL, etc but it all depends on what you mean when you say SQL (do you mean ANSI SQL or just in general a referential data mutation language?)

3 Likes
4

I think MaidSafe plan / had planned, to support sharing files among groups. They were also looking at how to notify of changes to a file, but said that’s hard (as if any of this is easy :slight_smile:)

I don’t have details - just recollections from discussions.

2 Likes
5

Alright, thanks for the replies so far. Not everything is clear but some more studying should remedy that in time :slight_smile:

At first glance it seems like a giant limitation to only have static + javascript – a tor hidden service seems like a much better match for that usage scenario, especially when considering that there are plans to improve hidden services and add built-in support for load balancing (not sure if that work has stalled/begun, though).

However, the idea of having a decentralized, always-on, censorship-resistant website certainly is intriguing! And for decades HTML+CSS did the job.

I’m not sure how other people interested in SAFE feel about javascript, but personally for me, as a daily tor user, it’s just something that is disabled unless it breaks the website and I really want to access it – the surface attack with js enabled is much higher.

Anyhow, I can imagine that for a very specific subset of things (it should be simple enough to publish a ghost blog to SAFE with minimal modifications, namely the database backend would have to be adapted to this environment [just write files to the fuse-mountpoint-to-be instead?])… so for journalism, spreading of ideas and so forth, it does seem like an even better solution than tor hidden services…

But at the same time, it’s hard to imagine the usefulness for anything more than trivial (by todays’ standards) when you consider that there can’t be dynamic logic applied other than on the client side. At least on the “http” side of things.

It also seems inherently limiting that, essentially, TCP/IP cannot be leveraged on SAFE and simple things like running a chat server become… well, as far as I can see it right now, outright impossible.

I’ve seen it mentioned that a decentralized chat service could be implemented, how would that happen? At some level the exchange of messages would have to be stored as files in the network, no? I dunno, either I’m missing something huge or it’s just very cumbersome and throws out years of evolution and refining to have to do it all client side and resort to representing essentially everything as files.

Thoughts?

6

Just to clarify, these concerns are mostly about the “web” side of things, the “private cloud storage” part of the concept seems very interesting, and in the future I can imagine guis that look more like dropbox or ownCloud in terms of client-side software, so essentially something that “normal” users are already used to, it should be pretty simple to sell that fish for the most part.

The inability to have fine-grained permissions certainly complicates things, but perhaps it can somehow be implemented on top… of course, I don’t have to mention the many usage cases where that would make sense, so if there is any way to bake into the protocol, in my very clueless opinion that would be much better!

7

@karnal:

I’m not sure how other people interested in SAFE feel about javascript, but personally for me, as a daily tor user, it’s just something that is disabled unless it breaks the website and I really want to access it – the surface attack with js enabled is much higher.

I agree there may be security issues with javascript (although I’ve never turned it off and never suffered as a result - so they may be overplayed). However, these risks are certainly reduced on SAFEnetwork, and easier to detect:

  • no servers to hack and insert rogue code into
  • javascript is source code, and visible to anyone who wants to look and see what it does
  • if you load a page from SAFEnetwork, you are loading immutable data so can be sure any particular item contains what has previously been verified (there are caveats with this - if for example the URL loads structured data, but I’m not sure about the limits of that. Needs clarifying).
8

This is an issue that I brought up quite some time ago…specifically for the uses for permissions for corporate uses such as private database access for data/doc storage for institutions, etc. It is possible to do but would be a layer on top of the core network. I think a problem is that the network is not designed to be able to recognize users or where requests are coming from (for obvious reasons) so building a feature in the network that does that would appear to be a bit counterproductive.

I think a lot of the features provided by current server tech and programming will be re-imagined by SAFE users to be accomplished in a different and better way using yet to be written solutions. I would think that is a better future for the network than simply dropping conventional server tech on the network and using it that way.

9

This might be completely offmark because frankly all the new concepts and different way of thinking when trying to visualize things in a SAFE manner (:smile:) don’t quite click yet.

But why not, for instance, have the built-in client automatically leverage PGP encryption, and these permissions would essentially be encrypting the data to one or more PGP keys?

The reference client itself could generate a set of identities and have random-looking pgp ids, then the public key could be exported in several ways, qrcode etc, and to make files readable only by certain users, then the user would simply select from a list of known public keys (gathered in the past from said people) all the intended users who should be able to read the data.

It could be possible to create groups this way, and map it to a bunch of PGP public keys stored in the client by the means freestyled above, so that it becomes less tedious to select the right people to encrypt to repeatedly.

To further simplify it even more, the private key for the users’ PGP key could be automatically encrypted with a very strong passphrase derived from the users’ SAFE credentials.

Maybe.

10

dirvine mentions a way to do kind of what you are looking at in this thread.

this may have some clarification…