Looks like a pre-launch app in Synereo are interested in utilizing the SAFEnetwork. I wonder if they realize that SAFE ‘storage’ is not an API you can access from the web.

Everything public about Synereo can be found here:
[PRE-ANN] Synereo: A fully decentralized social network owned by you

The Distributed & Decentralized Social Network
Your curiosity. Your family. Your hobbies. Your passions. The things you love and care about. Belong to you.


The beauty of recent developments based on the innovative Bitcoin blockchain technology is that they allow the public to claim control over previously centralized endeavours. By creating automated, trustless interactions over the network, we can now build systems that do not require concentrated power to maintain order. Rather, the power is spread throughout the network and is left in our hands, the active participants in it.

The Bitcoin revolution has brought us control over our money. In this position of control, we are its owners and we decide what to do with it, uninhibited by the interests of those in positions of great influence. Synereo is attempting to do the same, only with the fundamental social tool of the Information Age - the social network.

With current social networks, you are not the client. You are the product being sold - and for huge sums of money that you will never see. These massive corporations maintain extensive databases characterizing your behavior in an attempt to exploit the content that you create and the networks that you build with your friends and family. They’ve tapped into your deeply human need to socialize, with no respect for your privacy or psychological well-being, to turn your life into an endless marketing opportunity.

Your Identity is valuable. Your


All carry monetary value. Everything you do online is being tracked and monetized for someone else’s financial gain. And while these corporations tap into our most basic of needs, they demonstrate the ability - and, as a publicly traded company, a reason - to adjust their algorithms in a way that affects human behavior on a large scale.

We’re now in a unique position to take this power back from our social networks, to keep the value we create for ourselves, and put it to work for us. By disconnecting the application from its current axiom of generating revenue for its corporate owner, we can move development in the direction of supporting the network and its users. It becomes an ever-evolving social product, shaped to facilitate our need and desire to communicate.

Meet Synereo.

inquiry from synereo
laurence fass : Dec 03 06:01PM


im a member of the synereo dev team - a new distributed social
network - and we are evaluating distributed storage solutions. i would
very much appreciate if you can assist me with a couple of questions:

  1. do you have a testnet setup yet and if so can we contribute to testing?
  2. do you have any timescales on when storage will be ready for use in production?


laurence fass
Synereo dev team


I wonder if they realize that SAFE ‘storage’ is not an API you can access from the web.

Isn’t that what the Montreal POD are developing? In browser javascripted SAFE nodes / vaults presumably includes access to the RESTful SAFE API.

I was under the impression that this is a big no no…but then again, how will exchanges operate otherwise.

So yes that’s a big question…Devs?

I agree, needs clarification.

I think it’s something that can’t be stopped, so best for “us” to do it, and to limit the scope within foundation apps such as LifeStuff by not exposing LifeStuff comms e.g by NOT including gateways to old internet email etc., except as a way to invite folk - tricky one tho - if LifeStuff sends invites to the old net, people will demand we expose the gateway or fork it to do so. Maybe best to have LifeStuff field “invite” command by opening a traditional website invite page? Yuk!

@Viv sorry to distract, but is this an area you guys have beaten to death and have policy on, or still undecided?

The prototype I am building won’t be secure by default. However, should enough work is put into it to use in production, it could be used instead of a REST API since all the node operations will be local to the web page. The traffic that will come in and out of a single user browser will be similar to the traffic that come in and out of a regular SAFE node.

1 Like

Sorry Mark, not sure I follow this question. Are you referring to LifeStuff or similar apps being able to send messages via the SAFE network/traditional SMTP/… or is this about the NFS API itself as to the scope of it’s exposure ?

Just incase you decide to say “both” ;). I’ll maybe clarify a bit on each topic:

  • LifeStuff / any messaging app that try to work on traditional systems and via the SAFE network

I don’t really see this as a problem or something that can be “blocked”, It’s a feature that certainly helps if a user wants to get his friends or others into the network when they don’t have a SAFE public id. This is something that’s currently only to be done client side(the bridge between systems). Apps wouldn’t be able to send a message intended for SAFE://happybeing via SMTP and hope it reaches the right person on the SAFE network and vice-versa. This would essentially have nothing to do with the network itself in this topic.

  • NFS API itself as to the scope of it’s exposure

The data-storage API or NFS(Network-File-System) API is intended for a broad scope of users(devs I mean). So it is something which is a prime candidate currently to be exposed in ported languages / cross platform(desktop, mobile, …) environments. Now if for example a nodejs dev picks this port library for nodejs and decides to run his app in a browser, sure it’d run cos it’d be having a routing object on the same machine. Do note this allows network operations only from that machine where the nodejs app runs from, rather than traditional nodejs apps tht have a client and server part. If you then maybe have integration with something such as meteor, you’re expanding this scope. Same would ofc apply to a mobile dev targeting droid/ios/win in their managed languages and so on. If we take the route of a browser plugin that has a form of IPC for local actions in the client-side browser to a routing object in the same machine, you’ve again got access to the NFS API.

These are some of the reasons why the NFS API is currently being designed to cater for a very wide range of users(what I mean by that is simple and effective). We have systems like VFS-Drive that liaise with the underlying local filesystems that require a bunch of low level operations, while on the other side you’ve got dev’s who are familiar with traditional cloud storage such as amazon or azure or google providing’s that almost all give you a REST API. So Lee’s design is currently taking all these parts into account to provide what both sides would need.


Very helpful answers @Viv, thank you.

I was asking about policy on messaging, but as you illustrated, the question applies to the whole API.

Somewhere @dirvine expressed the desire to avoid mixing SAFE and IP messaging, but I may have misunderstood. Here you are saying there’s no intention to guide apps, away from acting as gateways (just to avoid exposing SAFE communications to IP routing, obviously).

So even LifeStuff might include a combined address book and allow messages to non SAFE id’s to be delivered via SMTP for example. It was that scenario that I was wondering about, and I think @chrisfostertv also had the impression @dirvine was against this I think.

dr00l :doughnut:


I think if a client does it then it is OK, with caveats though :slight_smile: I am against any core network component doing this though. Mostly because there is always a leak of some kind, even in a client we need to consider attacks on the client with insecure mails delivering a virus right into the clients machine / SAFE drive etc. It will be also a SAFE issue as well though, but the ability to get to a pop/imap port is pretty high in terms of intercept.


meaning that it is easy to spy on pop/imap messages?

This makes it highly desirable to at least offer a LifeStuff (all core client features) app, which does include any IP protocol gateways, for use by folk who want to just run a SAFE client with max security, and leave no footprint on the machine.

How about:
LifeStuff and LifeStuff Hermetic Edition?
or reversing the default so the first is more secure…
LifeStuff and LifeStuff Gateway Edition?


Yes they are generally not encrypted and always go through servers so their path can be tracked or just wait on the user getting messages etc. Its easy to telnet into smtp and mimic servers, some more than others, but it really is by design as hackers were not a consideration when they were built (like the internet)


Good idea Mark, worth keeping in mind, so whisleblowers / oppressed can easily spot any outbound connections to potentially less secure networks, maybe a clever client could glow red or something to let folks know clearly this is insecure comms or something.


Hackers are like sleuths so any information they can scrape anyhow is intelligence to infiltrate with. That means corporate secrets activities and personal interactions - legal ones are under assault by any ‘hacking’ entity. Glad MaidSafe tackles these issues head on.


I’m checked if I’m hacked by checking outbound connections, and monitoring my connections when trying any new third party apps almost always. This is a brilliant intrusion detection to be built into the appl.!

1 Like

In simple terms, if we think of two clouds, WEBcloud and SAFEcloud…

  • I can utilize WEBcloud to run vaults for SAFEcloud because it’s farming effective
    (for example, say the first 2 years)
  • Can the WEBcloud tap into SAFEcloud as a source of storage? (because it’s going to be cheaper at some point)

That’s what I was wondering with this Synereo, it sounded like they were intending running on WEBcloud, but utilizing SAFEcloud for storage.

I thought the answer was a definitive no, but if it was a yes…then it would certainly drive the value of SAFEcoin.

Hope I don’t confuse you further with this answer.

In this post, Let’s refer to

WebCloud : Amazon EC2
Instance : EC2 Instance

SAFECloud : SAFE Network

Now I’m assuming by this you mean, you’re using the EC2 API to create/deploy an EC2-Instance which will then run the SAFE network’s vault application.

Sure, this would work and now this EC2-Instance is essentially not only a part of the EC2 Cloud but also part of the SAFE Network.

If you now have the same EC2-Instance or even another EC2-Instance run a SAFE network client which has the NFS API functionality available, sure via this you could make network requests on the SAFE network for storage. If you make such a GET request to get this app running in an EC2-Instance to execute a SAFE network operation and return it’s result data back out of the EC-instance, security is pretty much a guess(where you’re hoping your privacy is respected) as you’ve taken the data out of the SAFE network.

If the driving force is purely to keep storage costs down at the potential cost of security then devs could ofc do it with such a wrapper client. Key concept is once data gets out of the network, security becomes questionable. Now if anyone would do it, or if users would use an app made with such a backend is a bigger question.

As for the EC2 API itself being able to directly perform network operations on the SAFE network, nope that wouldn’t work.

Thanks Viv, I think this was the answer I was after.

i.e I’m a data-center company, instead of building another warehouse of machines, I might be tempted to tap into this p2p SAFEnetwork and re-sell that space…but that’s not going to fly.

1 Like

Were you hoping to use an existing API with a maidsafe backend, so that no code changes were necessary on your part?

Not myself actually, just wondering if data centers could use SAFE as a virtual drive they could tap into and re-sell.

It would be good to be able to easily tap into API’s the other way though, make use of all that free or cheap space available. Maybe that would be a source of weakness for SAFEnetwork though, if providers of the free/cheap space start to shut down and the chunks need to replicate elsewhere in the system.