How is the NAT issue solved?

Hi, very interesting project!

Sorry for my ignorance, but I really wonder about one thing.
IMHO the biggest problem and the sole reason everything went “serverside” (has not always been like this) is that nearly every user nowadays is behind a NAT making direct communication hard and cumbersome, if not impossible.

So how does Blockstack solve this issue? Am I missing an important point?

Ah wait a sec, The answer might have just come to me.

Are you saying, that the clients are all only using dead data storage. So users don’t need to connect to each other, but only to the Data storages of their choice, like Google Drive, etc.? So I either set up my own, publically available data storage, or use one of the available cloud storages?

So when I want to read your data, I read it directly from your “shared” Google Drive account? And if I want to send you data? Does this mean you have to constantly pull from me to check for changes/new data?

Intersting…

Regarding storage, you’re spot on. If you and I share state in an app, then what happens is I write my data to my (publicly-routable) preferred storage providers, and you read from them. Similarly, if you want to share something with me in an app, you write to your preferred storage providers, and I read from them. However, I don’t write to your storage, and you don’t write to my storage. Instead, the app itself would mash up both our data to give us the same view.

For example, if we were using a shared calendar app in Blockstack, my calendar items would live in my storage and your calendar items would live in your storage. When I load the page, Blockstack would load both my items and your items and render them together. The app would find your storage providers through the Atlas network, and would find your public key (to authenticate your data) from BNS using your name.

Regarding polling, this is something we’re working on. Just like how we can each have our preferred storage providers, we can also have our preferred “multicast message channels” (e.g. an IRC channel, a ZMQ instance, a Comet endpoint, a phone number for MMS, and so on). If you’re using an app that gives notifications, then when I’m using the app, I’ll receive your notifications by subscribing to your preferred multicast message channels (the endpoints will be discovered through Atlas, just like the preferred storage providers are).

In the calendar example, if you updated a calendar entry while I was viewing the page, your browser would use blockstack.js to find my preferred messaging channel and relay a (signed) notification to my browser. The calendar app page running in my browser would receive and handle the message in some calendar-specific way (e.g. show a pop-up, update the calendar view, etc.).

This all happens under the hood, of course :slight_smile: . Blockstack Core has drivers for storage providers to give them all the same API, kind of like how your OS has drivers for various hard drives. This API is available through blockstack.js, which gives Blockstack Web apps a filesystem-like interface for reading, writing, and searching for files. Similarly, we’ll have drivers for multicast message channels that make them all look like Web sockets (or something like them) to Blockstack Web apps. At the end of the day, you can pick your preferred storage and messaging services, and Blockstack Web apps will be able to use them via blockstack.js without having to care about the implementation.

Thank you for this great and detailed explanation. Pieces start falling into place :slight_smile:

However the MMC part is not fully clear to me yet. I am not 100% sure who “you” is, in your explanation. The app developer or the user?

My biggest questionmark here is: How does your browser know, that my browser is looking at your page to send me a message?

My second one is: Do I need to sign up an account with all MMC’s to be able to send notifications to all kind of users? You even mentioned MMS which would cost money to use.

However the MMC part is not fully clear to me yet. I am not 100% sure who “you” is, in your explanation. The app developer or the user?

“You” is the user in all cases. The developer only writes the code. The users (you and I) pick our preferred storage providers and preferred MMCs.

My biggest questionmark here is: How does your browser know, that my browser is looking at your page to send me a message?

It doesn’t have to know. Through a bootstrapping step (described below), the app running in my browser knows that you are interested in receiving notifications when I make changes, so when it needs to send a notification, it (1) finds your MMCs via BNS and Atlas, and (2) uses blockstack.js to send a message there. The MMC will try to deliver it to you (i.e. if you’re connected to it at the same time), but it should drop it if it can’t.

Each app that would use notifications would have to have a bootstrapping step to know to whom it should send notifications. In the calendar app example, this bootstrapping step happens when I share my calendar with you. The app would remember that @CySlider should receive future notifications when I make changes to the app (i.e. it would keep a list of which users it’s shared with in my preferred storage providers, along with the calendar data).

When I’m in my calendar making changes, the app loads up the list of users with which it is shared, looks up their MMCs, and sends a notification to each MMC in addition to writing my changes to my storage providers. If you happen to be online and connected to your MMC at the same time, you’ll see the notification (i.e. the app running in your browser would update its view to reflect the changes I made). If you are offline, then nothing happens and the notification gets dropped by the MMC. When you come online later, you’ll see my up-to-date calendar when you load the page.

MMS is one of many mechanisms by which we could send notifications. If I didn’t want to use MMS, I would instruct my Blockstack Core node to never load its MMC driver (i.e. with storage today, and with MMC drivers in the future, you specify a whitelist of drivers to use).

Hope this helps!

2 Likes

Yes, very much, thank you.

Hi,
This relates to your reply rather than the OP’s question.
Is there a calendar app such as this, or one in development that you know about?
I am in the middle of working out my own requirements for such an app, I would be pleased to discuss this and my use case scenarios.
Also, just so as that I am clear, have I got it that Blockstack can work with a browser and local file system?
I could not quite believe my eyes (OK obviously javascript – but absolutely serverless!)

Just to add, the design of this forum is excellent.

Best.

Hi @adamsaltiel,

I haven’t begun working on it yet. I’m in the process of writing up detailed documents for the storage system, but the short answer is that yes, a Blockstack application will be able to interact with the local filesystem. More specifically, the Blockstack application will have access to the Blockstack storage system, which uses a user-chosen set of storage drivers for multiple back-ends (including local disk, but also including things like S3 and Google Drive) to automatically and transparently host and replicate the user’s data.

Hi @jude,
That’s brilliant.
Is your documentation requirements, code documentation or usage?
I can see that Blockstack has this and other storage apart from Dropbox as unimplemented links.
So I can continue to experiment outside of Blockstack with my own local drive as if implemented.
Is there more of a road map for blockstack and for further tutorials?
I can share with you directly more about my own use cases if this is of interest?

Hi @adamsaltiel,

The design docs for the storage system are up: https://github.com/blockstack/blockstack-core/blob/rc-0.14.2/docs/gaia.md

An API listing is coming soon :slight_smile:

I can see that Blockstack has this and other storage apart from Dropbox as unimplemented links.

The upcoming 0.14.2 release has support for local disk, Dropbox, Amazon S3, Google Drive, Onedrive, WebDAV, and SFTP. All storage providers are available through a unified filesystem-like API, described in the above link.

Is there more of a road map for blockstack and for further tutorials?

Yes; I’m working on a storage tutorial this week!

I can share with you directly more about my own use cases if this is of interest?

Let’s keep this discussion public, if you don’t mind :wink:

@jude public. Yes of course.
I probably need to create a new thread then, but I’m not there yet thinking things through.
I also have to think about how specific to get – I’m thinking if I’m too specific it is tedious for people or they wont get it.
So more thinking on my part needed.