Weekly Dev Update #61

Hey Y’all, 

This week we continued work on some key areas in Loki Messenger, including adding chat channel support for Android and iOS, and starting work on support for Loki Messenger across multiple devices. We also released an update to the Loki Storage Server which allows for the measuring of additional statistics, so we can continue to monitor the network and the success of the switch from testnet to mainnet for Loki Messenger. 

Loki Core

There’ll be a point release to Loki Core this week with a number of bug fixes that should increase Service Node stability. This is not a mandatory upgrade but is recommended for those running Service Nodes. 


Lokinet

If you’re on our Discord you can catch Jeff, the lead developer of LLARP, live streaming as he codes at https://www.twitch.tv/uguu25519. He typically streams on Tuesday mornings, 9am – 12pm Eastern (US) time.

What’s going on this week with Lokinet: 

Testing continues. We’ve identified a couple of issues related to existing sessions closing prematurely: we have a good idea where they are happening and are focusing on solving them.

Changelog:

New/updated/pending PRs:


Loki Messenger for Desktop 

Storage Server


Loki Messenger for Mobile (iOS and Android)

This week we released the APK for Loki Messenger for Android which means Loki Messenger is now available on all major platforms! We will be working hard to iron out bugs and improve the user experience of over the coming months.


Thanks,  

Kee 

Weekly Dev Update #60

Loki Developer Update #60

Hey Y’all, 

This week we finished up with the release of the Loki Messenger Android application. We also released the Loki Binance Bridge which was developed over the past few months and has now been open sourced on Github. Over the next few weeks we really want to focus on improving the user experience in Loki Messenger, and add lots of new and highly requested features like group messages, attachments etc… 

Loki Core


Lokinet

If you’re on our Discord you can catch Jeff, the lead developer of LLARP, live streaming as he codes at https://www.twitch.tv/uguu25519. He typically streams on Tuesday mornings, 9am – 12pm Eastern (US) time.

What’s going on this week with Lokinet: 

Lokinet is now feature frozen and in pre-release testing.  We’ve frozen the code to any new features and are testing it internally using various network environments.  The Lokinet team’s focus right now is to get the 0.5.0 release out and working; we’re putting off any major changes and improvements until a stable release is out the door.  This week has seen several fixes to minor issues found so far.

While we had intended for Lokinet to use IPv6 routing internally, testing revealed some problems with this approach (particularly in the non-Linux implementations), so we have deferred that change to a future release.  

Note: this isn’t a change to require IPv6 connectivity for Lokinet, but just for Lokinet virtual addresses to be IPv6 based.

Changelog:

New/Updated/Pending Pull Requests:


Loki Messenger Desktop 

Storage Server


Loki Binance Bridge 

This week we released the Loki Binance Bridge which facilitates swaps between Loki and B-Loki. You can test it out and get trading on the the Binance DEX right now by accessing https://lokibridge.com. Read about how it works on our blog: https://loki.network/2019/08/06/loki-now-on-binance-dex/.


Loki Messenger on Mobile (iOS and Android)

This week we also released the APK for Loki Messenger Android which means Loki Messenger is now available on all major platforms! We will be working hard to iron out bugs and improve the experience of using messenger over the coming months.


Thanks,  

Kee 

Loki Now on Binance DEX

Binance Dex Lists Loki

We’re extremely excited to announce that as of today (like, right now), Loki is listed on Binance DEX

That’s awesome! How’d you do it?

Glad you asked. To make it work, we’ve created B-Loki, a token on Binance Chain which is specifically engineered to provide a smooth and fast DEX experience where all trades are executed on Binance Chain. 

What’s the difference between Loki and B-Loki?

Good question. While we’re proud that Loki is fungible, private, and secure, B-Loki doesn’t maintain all of these properties. Rather, its main purpose is to allow trading on Binance DEX.

Cool. Can Loki be swapped for B-Loki?

Yes! Through the brand new Loki Bridge, which allows Loki to be exchanged for B-Loki (and vice versa) on Binance Chain. Functionally, the bridge lets you send Mainnet Loki coins and specify a specific Binance address where you will receive B-Loki. 

Okay. But is the bridge secure?

Loki Bridge has been built with security in mind, and uses a mixture of best practice techniques to match the security of many of the top exchanges in the cryptocurrency world.

Phew. So how does it work?

Like an exchange, when you deposit Loki into Loki Bridge, you’re relying on that exchange to credit your account in order to trade on it. However in this case, as the bridge is crediting your B-Loki or Loki Wallet, you only have to trust the bridge with your funds while a swap is in progress. As soon as the bridge has finished swapping your coins, you have full control of them in your nominated wallet.

And it’s trustworthy?

We’ve sought legal advice on the creation and listing of B-Loki in order to make Loki Bridge as trustworthy as possible. After assessing the available options, the Loki Foundation has contracted the operation of Loki Bridge to a third party provider, Lunar8. JP from Lunar8 is one of our earliest investors and is a trusted member of the Loki community who has advised and supported us since Loki’s inception (in fact, before Loki was even called Loki), and currently runs several Service Nodes.

The Loki Foundation maintains full rights to audit the bridge at any time, and works with the service provider to ensure that the correct amount of B-Loki and Loki is being held on the bridge at any given time. The service provider may never use the Loki held on the bridge for any other purpose than usage on the bridge (except for fees), and must adhere to strict security policies set by the Loki team.

Great. How long does it take to swap Loki to B-Loki? And B-Loki to Loki?

On average, swapping Loki to B-Loki should take about an hour. This is how long it takes for 12 chain confirmations on the Loki blockchain, plus a processing period to confirm everything on the backend. This time may reduce after checkpointing is enforced on the Loki mainnet and has proven itself to be reliable.

Swapping B-Loki to Loki should be much faster and take about half an hour. Since Binance Chain has a low blocktime, it reaches finality very quickly. However, there will be some lag due to processing time on the backend of the bridge. 

It’s worth noting that not all processing happens automatically: the bridge operator can choose to investigate swaps as they happen to ensure that incoming and outgoing balances match. This may add additional processing time beyond the normal period – as much as 24 to 72 hours.  

Is Loki Bridge decentralised? 

No, however once you’ve crossed the bridge and have B-Loki or Loki, you have full control over your funds again with your own private keys. The only centralised part of the process is the swapping mechanism.

Hang on. Is this some grand plan for Loki to switch to Binance Chain?

Not at all. We’ve built Loki Bridge to allow users to access Loki from additional places (including Binance Chain), however Loki will continue running on it’s own mainnet – it is critical to keep the Service Node network functioning. 

We hope Loki’s listing on Binance DEX is music to your ears. It’s another step forward for us in offering the best experience for our users, providing another place to acquire Loki, and adding to our growing list of integrations and features on offer. Check out Loki Bridge here.

If anyone has trouble using Loki Bridge, please head to our Telegram or Discord for support.

The Five Eyes Have Your Privacy in their Sights

The ‘Five Eyes Alliance’ – Australia, USA, Canada, New Zealand, and the United Kingdom – have recently discussed installing ‘backdoors’ into popular messaging services like WhatsApp, Telegram, and Facebook Messenger. A backdoor would allow high-level access (a.k.a. root access) to users authorised (or not) on a computer system, network or software application.

One proposed method is to silently add themselves to private communications, so they can monitor discussions undetected by others. Another is forcing software companies to implement certain ‘features’ or code that would allow them access to message content, sender/receiver names, locations, and other identifying data points. 

The Five Eyes Alliance believe these messaging services harbour terrorists, child abusers, and other illegal agents, and that by infiltrating these groups they’ll be able to prevent future attacks. While this sounds simple and admirable (we all want to stop the bad guys), the situation is far more complex, and the cost of allowing these tools to be implemented can’t be ignored. 

The problem is, backdoors create fundamental vulnerabilities in systems (some of the world’s largest technology companies including Apple, Microsoft, and Facebook have publicly voiced their concerns about them). While they may allow law enforcement agencies to do their job, they also open the possibility for others to get in, exposing us to criminal hacking, foreign espionage, and unlawful surveillance. 

But as well as compromising our security, backdoors compromise our privacy. With groups like the Five Eyes Alliance, we’re heading towards a world where all our communications are listened to, read, and watched – real Big Brother stuff. Sure, you may be thinking: I’ve got nothing to hide, what’s the big deal? But ask yourself this: why do you lock your door at home? Why do you shut your blinds at night? We don’t do these things because we’re criminals – we do them because they make us feel safe, because we like to have our own space, and we need time just to ourselves. 

Privacy is a human right in the physical world, and we believe it should be the same in the digital world. We want online communications to be truly private, and for our users to trust that when they have their digital door locked, or blinds down, no one’s secretly peaking inside. 

Weekly Dev Update #59

Hey Y’all, 

This week we’ve mostly worked on bugs that were affecting Service Node operators as they transitioned from lokid 3.0.X to the 4.0.3 suite of Loki Service Node tools. We published a new release for the Loki Storage Server and Launcher, and we have also made good progress on transitioning Loki Messenger to the mainnet so it can take advantage of the ~550 Loki Storage Servers.

Loki Core


Lokinet

If you’re on our Discord you can catch Jeff, the lead developer of LLARP, live streaming as he codes at https://www.twitch.tv/uguu25519. He typically streams on Tuesday mornings, 9am – 12pm Eastern (US) time.

What’s going on this week with Lokinet: 

All of the pull requests for the next version are either merged, or reviewed and to be merged in the next day or so. We are spinning up a distributed “toy” network to test the stability and functionality of the codebase in anticipation of a public release sometime in the next week or two (testing dependent). We also have internally-working debian packages for various recent Debian and Ubuntu versions to allow easy installation of Lokinet on those systems, and plan to release these with the public release.

Changelog:

New/updated Pull Requests:


Loki Messenger Desktop 

Storage Server


Loki Launcher

What’s going on this week with Loki Launcher:

With the launch of the Hefty Heimdall hardfork, the Loki Storage Server is now active. This week, after tracking down a number of bug reports submitted in Telegram and Discord about unexpected crashes, we found the suspect behaviour and put in a work around into the 1.0.0 release of the launcher. We also added a couple of fixes as a few new eyes were on the code, and improved its accuracy of status and startup.

Changelog:

  • Fix Storage Server pipe that would lock up Storage Server
  • Fix Storage Server stderr handler typo
  • SIGHUP guard fix
  • Double check running pid
  • Use SIGTERM instead of SIGINT to stop processes
  • Handle socket write errors better
  • Test socket for connectivity in status
  • Clear stale pid and socket files
  • Move uncaught exception log into var_path
  • Make sure Storage Server is running before startup is successful
  • Change version for git checkouts to be the last committed revision

Loki Blocks Onion Explorer 

The Loki Block Explorer has been expanded to show a number of new things including checkpoints and their votes, and decommissioned or inactive nodes. 

Loki Messenger on Mobile (iOS and Android)

We are very close to an Android release of Loki Messenger, and are now testing it internally in the office.


Thanks,  

Kee 

Weekly Dev Update #58

Loki Network Development Update 58

Hey Y’all, 

The Loki 4.0.0 hardfork is fast approaching! It’s happening in approximately 24 hours, so if you haven’t upgraded your Service Node, Miner or Mining Pool, now is your chance. If you don’t update in time, you will be left on an alternate chain and won’t be able to talk to the majority of the network.

A full guide on how to update can be found here: https://loki.network/2019/07/12/hefty-heimdall-mandatory-upgrade-period/

Loki Core


Lokinet

If you’re on our Discord you might catch Jeff, the lead developer of LLARP, live streaming as he codes: https://www.twitch.tv/uguu25519.  He typically streams on Tuesday mornings, 9am-12pm Eastern (US) time.

What’s going on this week with Lokinet:

Lokinet is entering a feature freeze for an upcoming release to the public, and is undergoing heavy internal testing to see how the network performs under various types of load.  We don’t have a fixed release date yet — it will depend on how testing goes this week, but look for one soon. The last several weeks of development have fixed a myriad of issues, big and small, and we think Lokinet will be ready for public testing soon.  Hence, we have internally frozen the codebase* to not add anything new (just important fixes!) between now and the 0.5.0 release.

* There is one exception; see below.

Changelog:

New Pull Requests:


Loki Messenger Desktop 

Storage Server


Loki Blocks Onion Explorer 

The Loki block explorer has been expanded to show a number of new things including checkpoints and their votes, and decommissioned or inactive nodes. 


Messenger Mobile (iOS and Android)


Thanks,  

Kee 

Hefty Heimdall Changes for Service Node Operators

There are a number of new and changing rules being implemented in the Loki Hefty Heimdall hardfork, and Service Node operators should make sure they’re aware of the new requirements.

The following changes will be implemented on July 24 at block height 321,467.

Changing Rules:

  • We have relaxed the Service Node deregistration rules in order to be more lenient on Service Nodes, particularly those that have previously demonstrated quality performance. 

New Rules

  • All Service Nodes must now run the Loki Storage Server to receive rewards.
  • All Service Nodes must now have an accessible Public IP address and must open ports for the Loki Storage Server.
  • There is now a penalty for Service Nodes that send their uptime proofs from different IP addresses.

More Detail:

Relaxed Deregistration: 

After reviewing feedback from Service Node operators on Discord and Github over the past 6 months, the Loki team proposed a number of relaxations (included in Hefty Heimdall) with regard to how Service Nodes are deregistered when they fail to meet the expected requirements. 

A few basic changes were made to implement the new system, including the introduction of a credit scheme and decommission/recommission transactions. The basic scheme is detailed below:

  • Each Service Node starts with 2 hours of credit.
  • Each Service Node earns 0.8 hours of credit per day of uninterrupted operation up to a maximum of 24 hours.
  • If a Service Node has been assessed to be no longer meeting the standards of the network (for example, not submitting uptime proofs) the quorum looks to see if they have any credit.
  • If the Service Node has 2 hours or more in credit, it will be decommissioned (instead of deregistered) for the amount of time it has in credit.
  • When a Service Node is decommissioned, its funds are not locked for 30 days but it is removed from the rewards pool and cannot participate in normal network functions.
  • If the Service Node starts sending uptime proofs again during the decommission period, the current quorum will detect this and submit a recommission transaction which will reset the Service Node’s credit balance to zero, and insert the decommissioned Service Node back to the bottom of the rewards list.
  • If, during the decommission period, the Service Node’s credit runs out before it can successfully submit an uptime proof, it will be deregistered.

TL;DR Service Nodes now have a longer grace period which grows the longer your Service Node is up and performing well. Service Nodes that have been running without interruption for 30 days will now have 24 hours where they can be offline before they are deregistered and your funds are locked for 30 days.

Read the full details of the relaxed deregistration rules here: https://lokidocs.com/ServiceNodes/DeregistrationRules/


Loki Storage Server:

The Loki Storage Server is an application that exposes a public endpoint for Loki Messenger users to be able to store and retrieve messages on your Service Node. It is a necessary requirement for Loki Messenger.

Hefty Heimdall versions of lokid running in Service Node mode will look for a running Loki Storage Server on your machine. If lokid does not find a running Storage Server, it will refuse to start. Lokid will also periodically check to see if the Loki Storage Server is still running – if it isn’t, lokid will stop broadcasting uptime proofs.  

You can easily manage lokid and the Loki Storage Server with the Loki Launcher, which sets up the required utilities. If you are an experienced system administrator, you can manage these utilities yourself – though we recommend you test your setup on testnet.

TL;DR You need to run the Loki Storage Server alongside lokid. Loki Launcher will do this automatically, otherwise binaries can be found here: https://github.com/loki-project/loki-storage-server


Public IP address and Open Ports:

All Service Nodes must now have a public IP address and open ports for lokid P2P and the Loki Storage Server. The default port for mainnet lokid P2P is 22022, and for the Loki Storage Server the default port is 23023.

If you are currently running your Service Node without any open ports or behind NAT, you will need to look into creating port forwarding rules in your router, and/or opening these ports in your firewall. If you are running a custom setup, you can change your default ports for Loki Storage Server and lokid P2P communications.

TL;DR You need to open ports in your firewall or router and have a public IP address.


IP Address Change Penalty: 

We understand that many Service Node operators in the community are running backup servers which submit uptime proofs for their Service Node. Most operators have set up these backup servers by running another lokid with the –service-node flags on a seperate IP, but with the same Service Node key as their primary Service Node.

This setup creates a race between the two Service Nodes, which compete to send out the first uptime proof. Depending on the precise timing of when the separate lokids submit their uptime proofs, the relationship between the two Service Nodes can change. You may find one is master for a while, and then it switches. You may find the two Services Nodes swap on every announcement. 

This race condition will be a problem in Hefty Heimdall because of the inclusion of the Service Node IP address in each uptime proof. Every time the server sending the uptime proof “wins”, it changes the IP on which the network tries to reach the Service Node’s Storage Server, and of course, the backup won’t have the same messages stored as the primary server.

Without modifying the Storage Server code to create a syncing channel between a master and backup Service Node, this problem is difficult to solve. Instead, the Loki team has implemented a punishment for Service Nodes that submit uptime proofs from different IP addresses. Each time your IP address changes, you will be dropped to the bottom of the rewards list losing your previous position. 

From talking to Service Node operators, we found that one of the most common reasons they ran Service Node backups was because they didn’t have enough time to respond to outages on their Service Nodes. By addressing the core issue – which was the lack of forgiveness in the deregistration rules – we think there will be far fewer people wanting to run backup Service Nodes. 

Although this change does not explicitly prevent the running of backup Service Nodes, Service Node operators who choose to run backup servers should ensure that they only send uptime proofs from the backup Service Node when it’s clear that the master server is actually down, rather than just setting up two Service Nodes and having both submit proofs at competing times.

TL;DR Running two Loki Service Nodes with the same SN key on two machines with different IP addresses will likely lead to your Service Node being dropped to the bottom of the rewards list regularly.


We are really excited to see these changes go live on mainnet on July 24. The Loki team and Loki community are always looking for ways to improve the stability and usefulness of the Service Node network, while maintaining a simple user experience so the Service Node network can continue to grow.  

Weekly Dev Update #57

Hey Y’all, 

This week was particularly busy as we worked towards the final binaries release for the mandatory upgrade period. Thank you to everyone who jumped on testnet and set up nodes – with your help we were able to identify a host of bugs which were fixed in our final 4.0.3 release. 

If you are a Service Node operator you should upgrade your node to version 4.0.3. Instructions on how to do this can be found here: https://lokidocs.com/ServiceNodes/SNFullGuide/#updating-your-binaries 

Loki Core


Loki Launcher

The Loki Launcher is a node JS package that will allow for the independent management of all the components required to run a full Service Node. This includes managing Lokinet, lokid, the Loki Storage Server and any other future applications we require. When Loki Service Nodes begin to route data and store messages for Lokinet and Loki Messenger, we’ll recommend that every single Service Node run the Loki Launcher.

What’s going on this week with Loki Launcher:

We released two versions of the Launcher this week for the 4.0.3 release. There were a lot of fixes for various crashes, but also support to be able to run versions 3 and up of lokid on mainnet. We also added extra startup checks to improve our status accuracy and made some minor user experience improvements.

Changelog:

  • Prequal additional configuration system for Storage Server
  • Update prequal ports to test
  • Rename port names, adjust prequal output
  • Abort launcher start up if Storage Server port is not open to the public
  • Handle “port is in use” error handling better
  • Store stdout/stderr for launcher when backgrounding
  • Add *-server-port-check args
  • Wait for blockchain-rpc port to be open before considering start up a success
  • Temporarily collect Storage Server startup info for 10s in case of problems with output
  • Report if the launcher was already stopped when stopping internally
  • Make sure certain modes are only run with root
  • Activate Storage Server based on blockchain binary version
  • Only pass version 4  parameters when blockchain binary version 4 or above
  • Reminders to restart loki-launcher if mode has stopped it
  • Strip out launcher arguments from passing all the way to blockchain startup
  • Remove duplicate Storage Server port check when backgrounding
  • Put try/catch guard around process check to prevent intermittent launcher crashes
  • When running port test submit a disconnect message when done
  • Add unhandled exception logger
  • Improve HUP information format
  • Process blockchain stderr
  • Make sure blockchain rpc server is up before starting network/storage
  • Change Storage Server default port from 8080 to 23023
  • Up retries for getPublicIPv4
  • Untangle retry counter with various repos in download-binaries

Github Pulse: Excluding merges, 2 authors have pushed 41 commits to master and 41 commits to all branches. On master, 14 files have changed and there have been 590 additions and 196 deletions


Lokinet

If you’re on our Discord you might catch Jeff or Ryan, the developers of LLARP, live streaming as they code: https://www.twitch.tv/uguu25519, https://www.twitch.tv/neuroscr

What’s going on this week with Lokinet:

The configuration refactor finally reached a state close to stable. There were lots of MacOS and FreeBSD fixes, and a huge internal change to using IPv6 on tunnel adapters to allow more connections to a hidden service or client.

Changelog:

Pull Requests:


Loki Messenger Desktop 

Storage Server


Loki Blocks Onion Explorer 

The Loki block explorer has been expanded to show a number of new things, including checkpoints and their votes and decommissioned or inactive nodes. 

  • Updated RPC changes around quorum state calls in 4.0.2 (replaced batch quorum calls with new quorum states call). 
  • Add checkpoint quorum display to quorum states page and to main index. 
  • Add display of a single obligations or checkpoint quorum, linked where appropriate.
  • Cut off quorum display after 20 nodes with a “+ 7 more ↪” that links to the full obligations quorum details.
  • Add a list of last three checkpoints to the main page (and a link to a page with up to 50 fully displayed). https://github.com/loki-project/loki-onion-blockchain-explorer/pull/1

Messenger Mobile (iOS and Android)


Thanks,  

Kee 

Hefty Heimdall Mandatory Upgrade Period

Hey Everyone!

It’s hardfork time again! The Hefty Heimdall upgrade period has begun, and that means everyone has approximately 12 days to upgrade to the latest versions of the Loki software before the hardfork on July 24. 

Below is a guide on how to prepare for the hardfork for each type of user in the Loki ecosystem: 

Wallet users

You guys don’t need to do anything yet. Over the course of the next two weeks we will be pushing updates to the Loki Desktop, iOS and Android wallets to upgrade them to the latest versions of the Loki software. 

Once these updates are released we encourage everyone to upgrade their wallet to the latest version, otherwise you will no longer be able to send transactions on the correct chain. 

Service Node Operators 

If you are using the Loki Launcher you can update to the latest binaries by using these commands: https://lokidocs.com/ServiceNodes/SNFullGuide/#updating-your-binaries.

For those more experienced with system administration and who aren’t using the Loki Launcher, you can upgrade your lokid binaries manually. Please note that you will also need to update to the latest Loki Storage Server. We have compiled a guide here: https://lokidocs.com/ServiceNodes/SNFullGuideLegacy/.

Pools

Pools do not need to enable RandomXL support until the hardfork on July 24 or at block 321467, however they should make sure they are ready to switch when the fork happens, and can look at these two reference implementations for changes they may need to introduce to their software.

A cryptonote-node-JS reference implementation pool which supports the new RandomXL Loki hashing algorithm can be found here: https://github.com/jagerman/cryptonote-nodejs-pool/tree/randomx.

A reference implementation for node-cryptonight-hashing can be found here: https://github.com/jagerman/node-cryptonight-hashing/commits/master.

A list of the full Loki changes to RandomX can be found here: https://github.com/loki-project/loki-randomXL.

Miners 

Miners can continue to mine Loki using CN-Turtle, however on the July 24 at block height 321467 they will need to switch to using RandomXL which is supported in a mining software called Xmrig on their “evo” branch: https://github.com/xmrig/xmrig/tree/evo. Xmrig have not yet published release binaries with RandomXL support, and if they haven’t published release binaries by the hardfork, we willl build and distribute mining binaries from a fork of their repository. 

Exchanges 

Exchanges will need to update their lokid and wallet with the latest CLI binaries found here: https://github.com/loki-project/loki/releases/latest. We will reach out to exchanges individually with any additional instructions if required.

Happy Forking!

Weekly Dev Update #56

Loki Developer Update #56

Hey Y’all, 

We’ve been busy bug catching this week! The testnet period for 4.0.0 Hefty Heimdall is still running, and we’re still working hard to track down a number of bugs that have appeared.  

Last week we released the beta version of Loki Messenger, which was well received. Through testing we discovered a number of bugs so we’ve released an updated version which can be found on Github. 

Service Node operators should download and update to the 3.0.7 release which includes security patches for some DoS bugs found in Monero. Click here for instructions: https://lokidocs.com/ServiceNodes/SNFullGuide/#updating-your-binaries.

Loki Core


Loki Launcher

The Loki Launcher is a node JS package that will allow for the independent management of all the components required to run a full Service Node. This includes managing Lokinet, lokid, the Loki Storage Server and any other future applications we require. When Loki Service Nodes begin to route data and store messages for Lokinet and Loki Messenger, we’ll recommend that every single Service Node run the Loki Launcher.

What’s going on this week with Loki Launcher:

We released the updated Loki Launcher for the testnet and got some real world testing done. Several bugs were found and squashed. Additionally our 3.0.7 release turned more users to the launcher for the first time. We took on all the community feedback and tried to reduce confusion to improve the user experience.

Changelog:

  • Version mode added
  • Read version from package.json so versions match
  • Handle stale socket and permissions in client mode better
  • Output where download-binaries is saving the binaries to
  • Add addition checks to make sure saved PID is actually a launcher PID (not another process)
  • Non-interactive alias for daemon-start mode
  • Refactor launcher, stop functions so more modes can make sure the launcher is offline before making changes: fix-perms, download-binaries
  • Put a try/catch around reading launcher.pid so we don’t exit if launcher.pid doesn’t exist
  • Fix filesize path in download-binaries
  • Fix double callback in download-binaries github api 403 retry handler (mainly for CI)
  • Run testnet tests on CI (was only doing mainnet tests before)
  • Add storage/network paths if enabled to fix-perms
  • Only report lokid_key if blockchain is running to reduce confusion (file exists even when it’s not running)
  • Always use debug mode in tesnet CI
  • Prequal now creates the storage data_dir if it does not exist
  • Lock testnet to preleases only
  • Bump package.json from 0.0.3 to 0.0.10, so git users don’t report the wrong version
  • Node 12.x (LTS version) testing and support
  • Only check for lokid key if Storage Server is enabled
  • 0.0.11 version bump
  • Add loadBlockchainConfigFile to handle lokid options better
  • Mute additional version outputs to reduce confusion
  • Be sure to take loki.conf into account
  • Update README, link dev reports
  • Don’t output daemon library version
  • If start up times out, report error code 1 (mainly for the CI to let us know there’s a problem)
  • Fix interactive bug with STDIN input
  • Update ifconfig.me’s service URL
  • Add start-debug mode
  • Alias set-perms for fix-perms mode
  • Rely on passed in config more (don’t repeat the work)
  • Move IPv4 detection until after it backgrounds to reduce confusing output on start
  • Add changelog to README
  • Fix downloadGithubRepo retry to not restart all repos of download-binaries but just the repo it’s currently trying
  • Add start up crash handler for launcher when backgrounding

Github Pulse: Excluding merges, 1 author has pushed 41 commits to master and 41 commits to all branches. On master, 14 files have changed and there have been 479 additions and 198 deletions.


Lokinet

If you’re on our Discord you might catch Jeff or Ryan, the developers of LLARP, live streaming as they code: https://www.twitch.tv/uguu25519, https://www.twitch.tv/neuroscr

What’s going on this week with Lokinet:

We tried to remove cppbackport and refactor the configuration system, however after review we decided to revert some changes. We also attempted to fix the broken MacOS port and made some minor protocol improvements.

Changelog:

Pull Requests:


Loki Locker

After taking feedback from the Loki Locker beta testing period, we will soon be releasing an updated version for public usage.


Loki Messenger Desktop 

Storage Server

Messenger Mobile (iOS and Android)


Thanks,  

Kee