[zeromq-dev] How do we activate and connect to WiFi hotspots in edgenets?
crocket
crockabiscuit at gmail.com
Sat Jan 11 22:48:22 CET 2014
I'm confused.
Is it an application hosted on the internet which communicates with peers
on the same WiFi network?
Or does it communicate with peers on the internet?
Does it use ZeroMQ at all?
On Sun, Jan 12, 2014 at 6:10 AM, Apostolis Xekoukoulotakis <
xekoukou at gmail.com> wrote:
> If there was, there would be no need to build it.
>
> Nobody has done it because
> a) indexedDB is quite new.
> b) It doesn't make business sense. You lose the revenue from the ads.
> c) They haven't thought of the idea of a durable socket.
>
> I got that idea from zeromq's guide(I think it has been removed now). The
> guide used it in case there was a failure and a client or server died. I
> transformed it to solve the problem of one person being offline.
>
>
> 2014/1/11 crocket <crockabiscuit at gmail.com>
>
>> Is there any real life application that does what you describe?
>>
>>
>> On Sat, Jan 11, 2014 at 11:30 PM, Apostolis Xekoukoulotakis <
>> xekoukou at gmail.com> wrote:
>>
>>> Ok, let me try.
>>>
>>> Problems
>>>
>>> a) 2 users want to receive data from each other but they cannot stay
>>> online all the time.
>>>
>>> sol: We add a third party in the middle that stores the information so
>>> that it will send it to the appropriate user when it goes back online.
>>> (durable socket)
>>>
>>> examples: the email system
>>>
>>> b) We want to have secure communication.
>>>
>>> sol: We use encryption.
>>>
>>> c) We want that data to be used by programs so that they present the
>>> data in a beautiful way or to precess the data and give us the result.
>>>
>>> sol: we need to store data in a format that is used in many applications
>>>
>>> d) Secure communication in general is possible. In practice, we dont use
>>> it because it requires great effort. How can we provide security with zero
>>> effort?
>>>
>>> sol: The Web is the most easy way to send and receive information. Our
>>> solution must be used by applications on the Web(social networks etc)
>>>
>>> e) Can the browser use cryptography and store data permanently?
>>>
>>> sol: yes. Nacl, openpgp and indexdb
>>>
>>> d) How can we trust that an app will use encryption and that it wont
>>> send data to NSA or add companies?
>>>
>>> sol: since all applications are in javascript, their code can be
>>> inspected.
>>>
>>> e) Do we need to trust the server?
>>>
>>> We only need to trust that the javascript code it gives us is secure. We
>>> can check the sha1 of the code to check whether it is the one we are
>>> supposed to receive. Keep in mind that there exist apps that work offline,
>>> they need to be downloaded once.( and verified only once)
>>>
>>> A simple example:
>>>
>>> We have 2 servers/delivery providers A.com and B.org.
>>>
>>> Alice signs up on server A with her public key.
>>> Bob signs up on server B with his key.
>>>
>>> A developer creates an application (that has nice social networking
>>> features like uploading pictures and posting articles)
>>> Alice asks A to host that application.
>>> A gets the application, the javascript code from the developer.
>>> It creates a random subdomain r.A.com to host the code.
>>>
>>> Alice tells Bob of that app, gives him the address of her provider
>>> A.com, her public key, a key specific for this app that bob will use to
>>> decrypt the data he gets from her.
>>> Bob does the same. (first he asks the provider to host that app if it
>>> hasn't already)
>>>
>>> Alice logs into A.com and gives the public key of Bob and the address of
>>> his provider(B.com) to A.com so that A.com accepts data from Bob for this
>>> specific application.
>>> A creates a durable subscription for bob's data for this specific
>>> application.
>>>
>>> So does Bob.
>>>
>>> Bob decides to use the app to upload a photo and create a post. The data
>>> are encrypted on the browser, are sent on his provider which in turn sends
>>> them to Alice's provider.
>>> Alice after she returns home, logs in her new application. The
>>> application retrieves the new data, decrypts them, stores them in the
>>> browser database and notifies her that bob has uploaded a new picture.
>>> The app shows the picture to Alice in a nice enviroment. She could edit
>>> the picture or comment.
>>> Alice finds the picture funny and decides to comment.
>>>
>>> ETC.
>>>
>>>
>>> 2014/1/11 crocket <crockabiscuit at gmail.com>
>>>
>>>> I can't imagine how it works or looks. Can you give us a concrete
>>>> example?
>>>>
>>>>
>>>> On Sat, Jan 11, 2014 at 7:36 PM, Apostolis Xekoukoulotakis <
>>>> xekoukou at gmail.com> wrote:
>>>>
>>>>> One alternative to a mesh network is of course peer to peer encryption.
>>>>>
>>>>> All browsers nowadays can persist data on their database.
>>>>> Nacl and openpgp have been ported on JavaScript. All we need then is
>>>>> an asynchronous delivery system that sends json to the browser.
>>>>> That is , exactly like email except that the updates are handled by
>>>>> the javascript application.
>>>>> We could create an api for any developer to create new JavaScript
>>>>> applications. Each such application would be hosted in a subdomain of the
>>>>> user`s preferred delivery provider and be given a unique delivery address.
>>>>>
>>>>> We could then have encrypted social network sites in a matter of
>>>>> weeks.
>>>>> On Jan 10, 2014 8:59 PM, "Lindley French" <lindleyf at gmail.com> wrote:
>>>>>
>>>>>> I haven't tried using it myself yet, but I believe one difference is
>>>>>> wifi direct has a programmatic API, which is not as easily exposed for
>>>>>> normal wifi.
>>>>>>
>>>>>> > On Jan 10, 2014, at 1:40 PM, Pieter Hintjens <ph at imatix.com> wrote:
>>>>>> >
>>>>>> > From what I know, setting up and maintaining a persistent WiFi
>>>>>> Direct
>>>>>> > connection is a painful user experience. Otherwise, it gives exactly
>>>>>> > the same results as enabling the hotspot on one phone and then using
>>>>>> > standard WiFi. (Unless i'm mistaken.)
>>>>>> >
>>>>>> >> On Fri, Jan 10, 2014 at 7:05 AM, crocket <crockabiscuit at gmail.com>
>>>>>> wrote:
>>>>>> >> Plus, I tested my nexus 5 and 7 with "Super Beam" app.
>>>>>> >> Super Beam shares files and folders using WiFi Direct.
>>>>>> >> My nexus devices successfully shared files via WiFi Direct.
>>>>>> >>
>>>>>> >> WiFi Direct is confirmed to be working at least on nexus devices.
>>>>>> >>
>>>>>> >>
>>>>>> >>> On Fri, Jan 10, 2014 at 5:31 AM, Pieter Hintjens <ph at imatix.com>
>>>>>> wrote:
>>>>>> >>>
>>>>>> >>>> On Thu, Jan 9, 2014 at 3:55 PM, Lindley French <
>>>>>> lindleyf at gmail.com> wrote:
>>>>>> >>>>
>>>>>> >>>> In the short term that may be the only solution that's workable
>>>>>> without
>>>>>> >>>> root
>>>>>> >>>> access on at least some of the phones. I think the full benefits
>>>>>> of
>>>>>> >>>> EdgeNet
>>>>>> >>>> won't be realized until arbitrary phones can serve as routers or
>>>>>> data
>>>>>> >>>> mules
>>>>>> >>>> without the user knowing or caring, though.
>>>>>> >>>
>>>>>> >>> Right.
>>>>>> >>>
>>>>>> >>>> I still think WiFi Direct has a place in the solution, when it's
>>>>>> >>>> available.
>>>>>> >>>> According to Wikipedia, only one phone of a group has to support
>>>>>> WiFi
>>>>>> >>>> Direct
>>>>>> >>>> for the entire group to use it.
>>>>>> >>>
>>>>>> >>> That works precisely like a hotspot afaik (did not actually try
>>>>>> that,
>>>>>> >>> though).
>>>>>> >>>
>>>>>> >>> -Pieter
>>>>>> >>> _______________________________________________
>>>>>> >>> zeromq-dev mailing list
>>>>>> >>> zeromq-dev at lists.zeromq.org
>>>>>> >>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >> _______________________________________________
>>>>>> >> zeromq-dev mailing list
>>>>>> >> zeromq-dev at lists.zeromq.org
>>>>>> >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>>>> > _______________________________________________
>>>>>> > zeromq-dev mailing list
>>>>>> > zeromq-dev at lists.zeromq.org
>>>>>> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>>>> _______________________________________________
>>>>>> zeromq-dev mailing list
>>>>>> zeromq-dev at lists.zeromq.org
>>>>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> zeromq-dev mailing list
>>>>> zeromq-dev at lists.zeromq.org
>>>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> zeromq-dev mailing list
>>>> zeromq-dev at lists.zeromq.org
>>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>>
>>> Sincerely yours,
>>>
>>> Apostolis Xekoukoulotakis
>>>
>>>
>>> _______________________________________________
>>> zeromq-dev mailing list
>>> zeromq-dev at lists.zeromq.org
>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>
>>>
>>
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>>
>
>
> --
>
>
> Sincerely yours,
>
> Apostolis Xekoukoulotakis
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140112/b23d93af/attachment.htm>
More information about the zeromq-dev
mailing list