LocationCore: Democratising personal user location data through the NEM blockchain

I have already explained above!

We are using NEM - LocationCore is built on NEM, we have written an SDK for NEM.

However financially with current blockchain fees it would not be feasible to run this at full scale the way we want (currently rather than performing a transaction every hour as planned - we are doing 1 per day to reduce fees).

If we were to push this live - we would be spending a minimum of 750 XEM per day (assuming 5000 users), this just isn’t feasible economically.

The release of Catapult would allow us to re-balance this somewhat and cut the burn rate right down - making it feasible. But Catapult is not ready on the public chain yet.

So as I said - while we wait for Catapult there is no rush to continue to push this development, it is still on our Roadmap but we have more important things to do that can be solved right now.

So what? You’re blasting complaints on a Japanese Telegram channel everyday.
What do you want to say?

Are you dissatisfied with the NCF?
Are you dissatisfied with catapult?

You should do the possible work now. It is not the fault of the NCF.
It is not the catapult’s fault either.
Please do your best. The Japanese community is waiting for the product to be completed.

Hey Dan,
You could put a forwarder to the domain name locationcore.com (and perhaps digital2go.com) which points to the new “LOCALLY Reward” website. That can avoid confusions, secure leads which read outdated web-content - and doesn’t cost a lot.
Greetings from Rene, LuxTag.io

I have made it clear that that we as a company are dissatisfied with the NCF and the whole handling of this funding in our case.

There is no catapult to be dissatisfied with. Mijin is not Catapult.

@GodTanu - we won’t complete any further work if there are going to be no milestone payments off the back of it - that is a final decision.

I am however doing my best to get the Readme finished for the SDK so we can push it out for the public to use and to open source what we can.

@r3n3 - we are having problems with the domain, it was registered through a previous service provider of ours and they let it lapse without notifying us. I will update the links in our when we have the relevant page on the new re-branded site!

Hi NEMbers,

Apologies for the delays on getting this out - we have had some heavy deadlines to reach with the other parts of our platform, however I wanted to fulfill our obligations to point the community towards the iOS SDK we created for LocationCore. This is based on NEM 1 and would thus need to be updated for Catapult in the future.

The SDK requires some kind of gateway to talk to the node network, in our case we used AWS Lambda due to its fault tolerant and scalable nature - as this is a mobile SDK this Lambda provides your single point of reference for your mobile apps considering the transient & decentralised nature of the node network. This is where you would transmit signed transactions to the node network and in a nutshell it needs to sign and execute a transaction.

The code below is just an example of how to sign and transmit a transaction, in reality you would have to handle connection pooling and failovers for unresponsive nodes.

var common = nem.model.objects.create("common")("", "yourprivatekeyheresecurely");

// Create variable to store our mosaic definitions, needed to calculate fees properly (already contains xem definition)
var mosaicDefinitionMetaDataPair = nem.model.objects.get("mosaicDefinitionMetaDataPair");

// Create an un-prepared mosaic transfer transaction object (use same object as transfer tansaction)
var transferTransaction = nem.model.objects.create("transferTransaction")(parsed.address, 1, "Message: " + transaction_message); //hard code 1 as the amount to act as a multiplier

/**
 * ATTACHING MOSAIC
 * No need to get mosaic definition because it is already known in the mosaicdefinitionMetaDatapair
 */

// Create a mosaic attachment object
var mosaicAttachment = nem.model.objects.create("mosaicAttachment")("locationcore", "lcc", parseFloat(parsed.amount) * 100);

// Push attachment into transaction mosaics
transferTransaction.mosaics.push(mosaicAttachment);

// Need mosaic definition of locationcore:lcc to calculate adequate fees, so we get it from network.
// Otherwise you can simply take the mosaic definition from api manually (http://bob.nem.ninja/docs/#retrieving-mosaic-definitions)
// and put it into mosaicDefinitionMetaDataPair model (objects.js) next to nem:xem (be careful to respect object structure)
nem.com.requests.namespace.mosaicDefinitions(endpoint, mosaicAttachment.mosaicId.namespaceId).then(function(result) {

    // Look for the mosaic definition(s) we want in the request response (Could use ["eur", "usd"] to return eur and usd mosaicDefinitionMetaDataPairs)
    var neededDefinition = nem.utils.helpers.searchMosaicDefinitionArray(result.data, ["lcc"]);

    // Get full name of mosaic to use as object key
    var fullMosaicName = nem.utils.format.mosaicIdToName(mosaicAttachment.mosaicId);

    // Check if the mosaic was found
    if (undefined === neededDefinition[fullMosaicName]) return console.error("Mosaic not found !");

    mosaicDefinitionMetaDataPair[fullMosaicName] = {};
    mosaicDefinitionMetaDataPair[fullMosaicName].mosaicDefinition = neededDefinition[fullMosaicName];

    // Get current supply
    nem.com.requests.mosaic.supply(endpoint, nem.utils.format.mosaicIdToName(mosaicAttachment.mosaicId)).then(function(res) {
        mosaicDefinitionMetaDataPair[nem.utils.format.mosaicIdToName(mosaicAttachment.mosaicId)].supply = res.supply;
        // Get current supply for mosaic
        nem.com.requests.mosaic.supply(endpoint, fullMosaicName).then(function(res) {
            mosaicDefinitionMetaDataPair[fullMosaicName].supply = res.supply;
         
            // Prepare the transfer transaction object
            var transactionEntity = nem.model.transactions.prepare("mosaicTransferTransaction")(common, transferTransaction, mosaicDefinitionMetaDataPair, nem.model.network.data.testnet.id);
    
            //create a keypair
            var kp = nem.crypto.keyPair.create(common.privateKey);
            // serialise transaction object
            var serialized = nem.utils.serialization.serializeTransaction(transactionEntity);
            // sign serialised transaction
            var signature = kp.sign(serialized);

            // build result object
            var signedtx = {
                "data": nem.utils.convert.ua2hex(serialized),
                "signature": signature.toString()
            };
            var finalArray = {};
            
            nem.com.requests.transaction.announce(endpoint, JSON.stringify(signedtx)).then(function(res) {
              
                finalArray.transaction = res;
                
                nem.com.requests.account.data(endpoint, parsed.address).then(function(res1) {
               
                    finalArray.account = res1;
                    
                    nem.com.requests.account.mosaics.owned(endpoint, parsed.address).then(function(res2) {
                     
                        finalArray.mosaics = res2;
                        
                        response = { "statusCode": 200, "body": JSON.stringify((finalArray))};
                        //transaction sent
                        callback(null, response);
                    
                    })
                })
            })  
        })  
    })  
})

I feel at the very least this will allow any other Swift developers to use this as a reference for how some of the crypto stuff is implemented (We based this implementation off Kailin’s .NET / C# code), however I would say that the most useful feature of this is that this code allows you to generate a wallet file (.wlt) that is compatible with Nano Wallet meaning it can be implemented into existing iOS wallets to provide some level of portability.

I hope this helps someone out who can contribute a larger Swift library to NEM.

2 Likes