Giter Club home page Giter Club logo

thali_cordovaplugin's Introduction

Thali Cordova Plugin

This project is a work in progress and not yet production-level quality.

The Thali Cordova Plugin is a Cordova plugin for building peer-to-peer (P2P) networking apps on Android and iOS.

The Thali Cordova Plugin is layered on the JXcore Cordova plugin, which uses JXcore to allow one to build mobile applications in JavaScript for Node.js.

The hacky work around instructions for using Thali in a Cordova project

One day the instructions in the rest of this document will be true. But right now we are really focused on just getting the code to behave itself and not on making it easy to use. We hope to fix that. But until then here are the instructions we use to build Cordova projects that use the Thali Cordova Plugin.

First off we aren't publishing to NPM right now. So that means you have to build the Thali Cordova plugin yourself. To get the instructions on how to do that please head over to test/README.md and follow the directions in the sections entitled 'Installing software' and 'Running your own NPM registry'.

From there you need to create your cordova project and install Thali into it. To do that I assume you are at the command line and are starting at the directory which contains the clone of Thali_CordovaPlugin.

cordova create FooBar com.example.foobar FooBar

The previous command will create a new Cordova project called FooBar in a directory of the same name in the namespace com.example.foobar. If you already have an existing Cordova project you want to add Thali to then you can skip the previous command. But you have to make sure that Thali_CordovaPlugin is a sibling directory to the one that contains your Cordova project. Note that for this and all other commands, if you have your own existing Cordova project, then please substitute 'FooBar' with the directory name of your Cordova project.

mkdir -p FooBar/thaliDontCheckIn/localdev

The previous command creates a directory inside of the Cordova project. This directory is a flag to Thali's install logic that tells us to pull the Thali code from a local clone of Thali_CordovaPlugin (that MUST be a sibling directory to the Cordova project) rather than trying to get it from NPM.

cd FooBar
cordova platform add android
mkdir www/jxcore
cd www/jxcore
vi app.js

The commands above take us into the Cordova project, add android (iOS isn't working yet so isn't in these instructions) and then create the www/jxcore directory. That directory is where all of your node code will live. In that directory you will create your app.js file that will launch your node code when your Cordova project is run. I used vi just to show that I created, edited and saved that file.

jx npm init

We are still inside of FooBar/www/jxcore and now we are running the script that MUST be run before installing thali since a bug in our installer. In other case install will fail. This script will go away as soon as installed fixed. See one of the reasons thaliproject/Thali_CordovaPlugin#1221, thaliproject/Thali_CordovaPlugin#1250 to run this script.

npm run setupDesktop --prefix ../../../Thali_CordovaPlugin/thali/install

We are still inside of FooBar/www/jxcore and now we are dealing with creating a package.json. If you don't already have a package.json, this will create one for you. If you already have a package.json then you can skip the previous command.

jx npm install ../../../Thali_CordovaPlugin/thali/ --save --no-optional --autoremove "*.gz"

This is the command, still in FooBar/www/jxcore, that actually installs Thali_CordovaPlugin. This command does a dizzying variety of things including setting up the Cordova environment with Thali's specific extensions as well as setting up the www/jxcore node app with all of Thali's dependencies.

jx npm install --no-optional --autoremove "*.gz"

Once you have Thali installed this next command will install anything else you have hanging out in your package.json.

find . -name "*.gz" -delete

You may have noticed above we have commands '--autoremove "*.gz"'. These are a special command in JXcore that does exactly what the line above does. However we have noticed that the command doesn't always seem to work so we just use the line above to be sure. The point of this command is that Android gets very unhappy if one tries to build an APK with gz files in it so we nuke 'em' before build.

cordova build android --release --device

And now we are ready to build! This assumes that you already have whatever content you want in your /www directory and in your /www/jxcore directory.

Now you are probably wondering - what now? The next step is to actually put in some code into that app.js and related files that uses Thali. Doing that is tricky and we will need to write an intro guide. But for now I would head over to test/www/jxcore/bv_tests/testThaliManagerCoordinated.js. This is the file that we use to test Thali all up. It shows how to use the only class you have to interact with to use Thali, thaliManager. Look for 'new ThaliManager(' and also look at the thaliManager.js file which contains JSDOC.

The basic idea is that you have to give us the version of ExpressPouchDB you want us to use as well as the version of PouchDB. In the case of ExpressPouchDB head over to test/www/jxcore/package.json and see what version of ExpressPouchDB and Pouchdb we are using. Put those exact versions into your package.json. Don't worry if they look funky, we sometimes build our custom versions and stick them in Sinopia when we are building so everything should work if you followed the instructions above.

In addition we assume the PouchDB object you give us is configured with the right directory for us to open databases and that you have set the default adapter to LeveldownMobile.

The command to do this yourself looks like:

PouchDB = PouchDBGenerator(PouchDB, defaultDirectory, {
  defaultAdapter: LeveldownMobile
});

Where PouchDB is the PouchDB object your required. defaultDirectory is the place you want to stick the DB and the last argument sets the adapter for leveldownMobile. So you can just pass the above into thaliManager for the PouchDB argument.

In Thali's model we use local radios to sync exactly one database (it's a silly restriction but we are trying to do less for the moment). The name of that database is submitted in the next argument. The name is submitted because for a variety of reasons having to do with how remote synching is handled we have to create our own instance of PouchDB pointing at the named DB. This doesn't however restrict use of the same DB by code running in Node outside of Thali. PouchDB is 'multi-access' safe within a single running instance of Node. So you can party on the DB at the same time we are and it should all be fine.

After that is the device's own public key. This is used to identify the device to other devices.

var ecdhForLocalDevice = crypto.createECDH(thaliConfig.BEACON_CURVE);
var publicKeyForLocalDevice = ecdhForLocalDevice.generateKeys();

Again, see testThaliManagerCoordinated.js for the relevant includes. The code above creates a new public key object with a specific curve, then generates a public/private key pair matching that curve. We have to use this specific curve so don't change it.

Note that the private key can be retrieved via getPrivateKey() and stored somewhere secure on the device. This key will be needed the next time the device runs to create a new ECDH object in the future using setPrivateKey(). Note that JXcore runs an old version of node so to get accurate docs on how it handles crypto please refer here.

The point is that once a device generates a public/private key pair for itself it is expected that the device will continue to use the same key pair in the future. Otherwise we can't reliably discover other devices.

After the public key comes a particularly tricky piece of code, the Thali Peer Pool Manager. See the thaliPeerPoolInterface for details. For now you can start with the thaliPeerPoolDefault.js whose behavior is incredibly inefficient and will burn down your batteries and kill your bandwidth, but it's a start. We'll need to write a fairly length article to explain all the things that the peer pool manager has to do.

Finally, the last argument specifies what kind of networking you want Thali to support. The enum for this value is defined in thaliMobile.networkTypes. For now just set it to WIFI but you can also play with NATIVE. Right now we have show stopper bugs on both so expect some rough going. Eventually the right solution for everyone will be BOTH (which tells us to use both local WiFi access points and the native radios). But we aren't there yet.

Once you have created the ThaliManager object then the next step is to actually start it. Unsurprisingly this is done with a method called (wait for it) start. However it's argument is extremely important. It is an array of buffers that contain ECDH public keys. This is the list of public keys for other devices that this device should both advertise information for and seek information from. The public keys that go into this array are the value returned above for publicKeyForLocalDevice. Now, the obvious question is, how did device A get the public keys for devices B, C, D, etc.? The answer is - we don't know. :)

Eventually we'll bring back the identity exchange infrastructure that lets one exchange public keys securely between devices but our current primary customer, Rockwell Automation, doesn't need that functionality. They will actually sync the public keys via the Rockwell cloud. So their app depends on devices having, at some point, connected to the cloud in order to download a list of public keys. If you don't happen to have a handy cloud then you need to figure out your own solution for how to distribute the keys. Anyone wanting to resurrect the identity exchange code can contact us via any of the mechanisms listed here. Alternatively you can just cheat. Set up an open PouchDB/CouchDB server some place and have devices sync their keys there and then sync down from that server all the other device's keys. It's a hack to get you going.

Any time the list of keys change the start method needs to be called again. Also note that we currently limit the number of keys we'll handle to 15. But this value can be set in thaliConfig.js.

When you are ready for Thali to stop using up the device's batteries via radios you can call 'stop'.

That is about it. If it works then anything you stick into the database you gave us the name for should be sync'd to the other devices you told us about if they are around and vice versa.

Useful commands to run Android apps via command line

Build

cordova build android --release --device

Sign unsigned

cordova build creates unsigned apk. So in order to install the apk into device you need to sign the apk.

Please note that build-tools should be at least 25.0.0. Because this guide uses tool apksigner that is available starting from build-tools 25.0.0.

You should have keystore file before running the command below.

/usr/local/opt/android-sdk/build-tools/25.0.0/apksigner sign --ks path/to/keystore/file path/to/unsigned.apk

Get devices list

You need to know device serial number or qualifier to install build into device via command line. The command below lists all connected devices with their qualifiers (first value in each line).

adb devices -l

Install onto device and debug

adb -s DEVICE_QUALIFIER install -r path/to/signed.apk

Please note using logcat if you need providing the team with the logs from devices.

Prerequisites

Android

Download Android Studio or the latest android-sdk

On Mac OS android-sdk can be installed from brew:

brew install android-sdk

Make sure to set your ANDROID_HOME environment variable:

If you have already installed android-sdk the correct ANDROID_HOME environment variable was set automatically.

Otherwise set ANDROID_HOME environment variable manually:

Mac OS X (put in your ~/.bash_profile file):

export ANDROID_HOME=/<installation location>/android-sdk
export PATH=${PATH}:$ANDROID_HOME/tools:$ANDROID_HOME/platform-tools

Linux (put in your ~/.bashrc file):

export ANDROID_HOME=/<installation location>/android-sdk
export PATH=${PATH}:$ANDROID_HOME/tools:$ANDROID_HOME/platform-tools

Windows:

set ANDROID_HOME=C:\<installation location>\Android\sdk
set PATH=%PATH%;%ANDROID_HOME%\tools;%ANDROID_HOME%\platform-tools

<installation location> can vary on different platforms but it's something that contains android in path and with folders inside like etc, platforms,samples,tools and so on.

Real life Mac OS ~/.bash_profile example:

export ANDROID_HOME=/usr/local/Cellar/android-sdk/24.4.1_1/
export PATH=${PATH}:$ANDROID_HOME/tools:$ANDROID_HOME/platform-tools

Above <installation location> is /usr/local/Cellar/android-sdk/24.4.1_1/

Current API target level is android-21

iOS

Download Xcode 8, or later.

Getting Started

Install latest JXCore

The installation guide for JXCore 3.1.14 on Mac OS and Windows can be found here.

The latest version of JXCore 3.1.14 only for Mac OS can be downloaded from here

To check the version of the current JXCore installation run:

$ jx -jxv
v 0.3.1.14

Install Cordova

(Check the Android Platform Guide and iOS Platform Guide for detailed instructions.)

$ npm install -g [email protected]

Create a Cordova project

$ cordova create ThaliTest com.test.thalitest ThaliTest

Using the Thali Cordova Plugin

To use Thali in a Cordova project one must do the following:

  1. Make sure to add whatever platforms you are using in Cordova using cordova platform add (android | ios)
  2. Add a subfolder to www named jxcore (case sensitivity matters)
  3. Inside the jxcore folder create the app.js for your application
  4. Inside the jxcore folder create the package.json for your application
  • jx npm init provides an easy to use wizard that will create a basic package.json file
  1. Inside the jxcore folder run the command jx npm install thali --autoremove "*.gz" --save
  2. Make sure to run cordova build as this is critical to moving key files into place

Now you can run your app. The Android devices need to have OS version Lollipop or later for things to work properly (Thali uses class BluetoothLeAdvertiser, which was added in API level 21). Android 6.0 "Marshmallow" introduced a new permissions model where the user has to approve use of dangerous permission while the app is running. Thali Cordova Plugin requires ACCESS_COARSE_LOCATION which needs user approval. This approval can be requested calling window.ThaliPermissions.requestLocationPermission() function. ThaliPermissions API locates at www/android/thaliPermissions.js.

Note that Thali uses a subdirectory in your project called thaliDontCheckin to manage certain downloads. Per the name of the directory, please don't check it in to your repro.

If you want to upgrade to a newer version of Thali_CordovaPlugin all you have to do is just edit your package.json with the version you want and then run 'jx npm install'. This will automatically update the Javascript files as well as uninstall the old plugin and install the new plugin.

Troubleshooting

In case of Thali failures do the following first.

  1. Go into cloned Thali folder and execute the following command find . -name "node_modules" -type d -exec rm -r "{}" \;. WARNING: Use rm -r with caution it deletes the folder and all its contents.
  2. rm -r ~/.jx
  3. rm -r ~/.jxc
  4. rm -r ~/.node-gyp

Documentation

The following API documentation is available for the Thali Cordova Plugin:

Contributing

If you see a mistake, find a bug, or you think there is a better way to do something, feel free to contribute. Email [email protected] to connect with other contributors and get started with Thali.

Code of Conduct

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact [email protected] with any additional questions or comments.

License

Copyright (c) 2015 Microsoft

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

thali_cordovaplugin's People

Contributors

andrew-aladev avatar artemjackson avatar asuhodolov avatar baydet avatar chapko avatar cicorias avatar czyzm avatar deadlyfingers avatar dersim-davaod avatar drinkius avatar evabishchevich avatar iserzh avatar jareksl avatar juhanak avatar larryonoff avatar lesn1kk avatar mattpodwysocki avatar mlesnicrockwell avatar mohlsen avatar mpodwysocki avatar obastemur avatar opetkevich avatar softwarenerd avatar sreesharp avatar srichal avatar tobybrad avatar tompaana avatar vasilevskayaem avatar vjrantal avatar yaronyg avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

thali_cordovaplugin's Issues

Background mode dies on iOS 9

The latest beta of iOS 9 has broken something really fundamental in the code we use to do BLE in the background. Brian is investigating and filing issues with Apple.

Get JXCore to expose native key stores

We keep our public keys in PKCS12 files which have a password that is used to encrypt them. But that password is just a string that is burned into our app. We don't even both to randomly generate that string since we would then have to save it in a file right next to the PKCS12 file, so what is the point? We are trying to make sure that the PKCS12 is in app only storage (so other apps can't get to it) but that's about it.

Both iOS and Android do provide for 'key stores' but they are not really useful in my personal opinion. The reason is that both just end up storing a file with the secrets encrypted using a key derived from the device key. So anyone who breaks the device key can get to those keys no problem.

In fact I would argue that the key stores are completely useless for anyone who encrypts their phone drive since that too is encrypted with a key derived from the device key.

Nevertheless if someone has a phone that isn't encrypted but does have a device key and so is 'locked' then using the key chain provides some tiny amount of protection against completely unsophisticated attackers.

So we probably should get JXCore to expose an API to access the mobile platform's key store and then use it.

Fix looking for peers forever in iOS

Right now our iOS discovery code will discover a peer via BLE exactly once. The reason is that we have suppressed multiple discovery notifications because otherwise we get hit about 1000 times a second (yes, literally) with notifications.

The problem is that once we suppress duplicates it means we will literally, never get a notification for that user again (at least as long as the app keeps running, including time in the background).

So what do we do when the user leaves the area? The answer is that we have a long poll BLE connection request to EVERYBODY we discover. And we keep this connection request indefinitely. So if the person disappears the request will fail and we will know and if they come back the request will again work and we will know they are there.

But this potentially means that our list of discovered peers can grow without bound. It's not clear in practice how big a deal this is since presumably when we put in the correct discovery framework we will only bother with the long poll for peers we have ever had anything to do with. But it's still not ideal.

It seems that if we turn discovery off and back on then the iOS device will clear the cached identities it isn't providing notifications for and we can start afresh. For security reasons (we don't want to expose our identity by constantly connecting to the same people) we probably want to periodically turn off and on discovery to clear the list.

Need to agree on logging solution for Android

We need to be able to configure our logging on Android using a framework like log4j or the built in Android logging. We specifically need support for:

  • Setting different levels of logging
  • Being able to set different levels of logging for different components
  • Being able to log to rotating local files where we can delete old files
  • Being able to log to a remote server for when we run tests in the testing lab

minimum Android SDK Decision

This plugin requires min SDK 16 (4.1) BLE introduced with 18 (4.3) The requirement document says min 4.4 (19)

So, any objection for 19 ?

Automate test set up

Once you have the automation set up for the main plugin install we also need to automate the test set up.

Ignore files on android build

In step 7 of android build to exclude *.gz from build use the ant.property aapt.ignore.assets

I think I set an environment variable for that I'll check later what that was.

How do we rotate Express-PouchDB's logs?

Express-PouchDB generates its own logs. We either need to figure out how to redirect the information into our logs or we need to figure out how to make sure the logs don't grow without bounds.

Remove the Thalitest specific files

Right now we use app.js and the root package.json and index.html and a bunch of other files that we require to be moved over to whatever project is using us. But in the process we actually overwrite the files in the project that is using us. After all, that project will have its own index.html and its own package.json and its own app.js.

What we need to do is remove all the Thalitest specific files and we need to format our JS code so that it is a NPM module that the user can then require().

Couldn't download the btconnectorlib2 package in Windows

Steps to reproduce the issue


  1. Create a cordova app in Windows 8.1
  2. created jxfolder inside www folder
  3. Added Android platform using 'cordova platform add android'
  4. Installed the plugins using 'jx install thali'
  5. build using 'cordova build android'

Expected result - Build should be successful
Actual result - Couldn't locate the btconnectorlib2 library, and build failure

We are getting bad closes on syncRetry

Take a look here specifically at the 8-10 09:50:24.741 entry where we are getting Error!: Not Running exceptions. This is a close call on a socket that is already closed. This shouldn't happen. It means our state model is broken since we should know if the socket is already closed.

mobile.isDebug - Is this a job for JXcore?

I've filed bugs #70, #71 and #72 for us to implement our own isDebug call from JXcore to the native layer. We need this because the way we set up things like logging changes depending on if we are in debug or not. But it occurs to me that this is exactly the kind of functionality that everyone using JXcore is likely to need so it could be a really great addition to mobile. What do you think?

Need to agree on logging solution for iOS

We need to be able to configure our logging on iOS using some framework that supports:

  • Setting different levels of logging
  • Being able to set different levels of logging for different components
  • Being able to log to rotating local files where we can delete old files
  • Being able to log to a remote server for when we run tests in the testing lab

Radically simplify Thali Cordova Peer Communication API

This issue is about proposed changes to https://github.com/thaliproject/Thali_CordovaPlugin/blob/story_0_matthewp/doc/api/replication.md to make it much simpler.

Proposal 1 - Remove "currentMachineIdentifier" argument from StartBroadcasting. We always have to broadcast our high bandwidth transport ID when we announce ourselves so the native code should just handle this for us. In other words Android should always advertise the Bluetooth UUID and iOS should always advertise the Multi-Peer PeerID.

Proposal 2 - Get rid of Disconnect. Instead specify explicitly that any time we kill the TCP connection to the TCP client bridge then that means we want to kill the connection to the remote peer. Yes, I know the perf on this is awful. We'll fix it later. But for now simplicity is a feature.

Proposal 3 - Get rid of GetDeviceName. We really and truly don't need it. For now the "deviceName" value passed into StartBroadcasting should be the user's actual name that they will pass in via the post card app and in the future we will be doing something completely different involving crypto magic.

Proposal 4 - Get rid of GetKeyValue and SetKeyValue. They were intended for advertising extra information using either BLE properties or mDNS but since we don't really support either at the moment there is no point in having APIs that don't do anything.

Proposal 5 - Get rid of MakeGUID. There is literally no reason for it to exist. We can generate GUIDs in Node.js. No reason to add another native binding.

Proposal 6 - Get rid of GetFreePort. I would actually argue that this method is actively harmful. The reason is that between the time that you check to see if the port is available and when you actually use it someone else could claim it. What someone should do is pass 0 into their listener on Node.js and it will automatically grab a free port. So this function does not need to exist at all.

@DrJukka and @deadlyfingers both need to review.

Replication is not happening with 3rd device

I have installed the latest PostCard app in three android phones, and trying to replicate the cards across all the devices. At any point, the replication is happening between only 2 devices. If I kill all the apps, and restart again, replication might work work with different pairs, and leave one device alone.

Make Android connect code respond faster

Right now we return the port in the callback from the connect method at the node.js layer. This is potentially bad because the native call out in JXCore is synchronous and right now the Android code will set up the bluetooth connection and only then return the port, a process that can take many seconds. During that time the node.js engine is at a full stop.

So we have two choices to fix this:

  1. We can change the API so that the port comes back as an event rather than in the callback from the native call out.
  2. We can change the Android code so that we grab a TCP port for our listener, return that immediately and only then start trying to get the bluetooth connection. We have to add some code to be smart so that if node.js connects to our port while we are still trying to setup the Bluetooth connection we have to accept the connection without actually reading or writing any data to it until Bluetooth is ready.

Write and get passing tests for the Mux layer

We are only worried about the mux layer, not the replication manager, because the replication manager code is all going to be replaced in the near future. But the Mux layer is something we expect to stick with and eventually release as a stand alone project.

Make Deployment Not Suck

When someone installs the thali_cordova plugin the only thing they should have to do is execute 'cordova plugin add thali_cordovaplugin', they shouldn't have to follow all the manual steps we have specified that includes fixing min-sdk, replacing files, copying code and even running npm install. All of that should be completely automatic.

Does getDocumentsPath return app only storage?

In Android there is an idea of storage that just belongs to an app and "general storage" that any app with local read permissions can get to. I don't know if iOS has a similar feature.

Does getDocumentsPath return app specific storage or general storage? This matters in our case because we are storing private keys and we need to make sure they aren't in general storage.

Clean up manual steps on Android

We have a bunch of manual steps needed to use our cordova plugin on Android. We need to fix that so that everything is automated.

We need more native tests

Tests should include fun things like:

  • Actually sending data!
  • Re-running our existing native tests but with an active connection, for example, what happens if we try to connect to a fake peer when we have a live connection?
  • Connecting to a peer, sending data, disconnecting and then reconnecting and sending some data.
    This is all basic stuff. In another milestone we can get fancier with having peers disappear (we can even write a simple test server that lets one peer tell another peer to stop broadcasting for some fixed period of time). But later.

Need a 'isDebug' native API call

We need to expand the Native API to add a call to tell if we are in a debug build or a production build. We primarily need this now to set our logging.

'jx install thali' is not installing the plugin second time

Steps to reproduce the issue


  1. Create cordova app, and jxcore folder inside www
  2. run 'jx install thali' inside jxcore folder
  3. uninstall the thali plugin using (cordova plugin remove org.thaliproject.p2p)
  4. run 'jx install thali' inside jxcore folder
    Expected result - org.thaliproject.p2p and io.jxcore.node should be there in plugins folder
    Actual result - thali plugins are not there in plugin folders

Create replication manager

We need the "0" story replication manager. See http://thaliproject.org/stories. It's not very smart. It hooks into discovery and will immediately do a push/pull synch with anyone it discovers. It will also hook into the local PouchDB instance's change feed and do a push replication anytime it sees a change.

We need to have an api to detect if bluetooth, wifi or BLE is available

We need to return detailed status information if the radios are off in StartBroadcast and the network state event needs to also specify network data. We specifically need to know if discovery and/or p2p are available. This needs to be abstract because it should work the same way for Android and iOS even though they use different technologies.

We also need an API to turn on the discovery or p2p functionality. This will only work on Android since I don't believe iOS lets these work under programmatic control.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.