Forem: Wietse Wind

Hooked #0: Intro

Wietse Wind — Thu, 30 Jun 2022 22:27:00 +0000

Please note

Since this blog was published a lot has happened. The Hooks Amendment is now running on a public testnet and has a public "Builder" where you (devs) can code Hooks and deploy them to the testnet, straight from your browser.

(Cross post: this article was posted here on July 30th 2020. More blogs have been published since)

XRPL Labs is working on the transaction "HOOKS" amendment for the XRP Ledger. Supporting business logic integration for developers.

The XRP ledger is known and is being appreciated for its transaction throughput, speed and the low fees. Combined with available advanced transaction types like multi sign, escrows, payment channels and even a decentralized exchange (all on ledger, out of the box, without requiring smart contracts) the XRPL has a lot to offer businesses and (creative) developers.

At XRPL Labs we build XUMM (and other, smaller libs. and projects). While building a product & business leveraging just about all things the XRPL has to offer, we’re continuously looking at the XRP ledger from developer, consumer and business perspectives.

We realized that, while the XRP ledger already has a lot to offer, developers and businesses need a lot of flexibility, allowing them to not only build what is possible today, but to build what they can imagine tomorrow. For XUMM, we’re looking at tomorrow (and the day after, our three year roadmap and beyond)

Think about (just to name a few):

Auto saving on incoming transactions. Automatically park VAT, send a part of your received on ledger pay to your holiday savings account, …
An on ledger Tip / Gift platform (bot), to individuals, charities, opt in infrastructure (validator) rewards, etc. Using “Lite Accounts”, without account reserves.
“Lite Accounts” so businesses can assign & track loyalty points for all their customers, on ledger, without having to activate their account.
On ledger subscriptions to advisory lists like the XRPForensics list, to auto block incoming & outgoing transactions from and to scams, no matter the used XRP ledger client
Storing account based flags, like “did this user perform and passed KYC”
On ledger if/else (or more advanced) conditions on incoming or outgoing payments, based on your own logic, possibly using data provided by oracles

While envisioning multiple on ledger features (samples below) for XUMM, we quickly realized that most features would be best implemented on ledger, non custodial, as we (and many other developers and businesses) don’t have (or want to get) the appropriate licenses for handling user funds, custody, etc. And we were only talking about the features we could come up with. Imagine what would happen if other businesses, creative developers, use cases out there found their way to a flexible way to add on ledger business logic to transactions on the XRP ledger.

We decided to call our idea “Hooks”. Transaction Hooks. They are small, efficient pieces of code being defined on an XRPL account, allowing logic to be executed before and/or after XRPL transactions. These hooks can be really simple, like: “reject payments < 10 XRP”, or “for all outgoing payments, send 10% to my savings account” or more advanced. By allowing hooks to not only execute efficient logic but also to store small, simple data objects, one could define a hook like: “for incoming payments transactions, check if the sending account is in a list maintained by another hook, and if present: reject the transaction”.

We are currently thinking things through, drafting what an implementation would look like. We’re turning that into open source code and a proof of concept, then to develop a first version and run it on our own (private, after that: public) XRPL testnet. We’ll be focussing on everything required to protect the XRP ledger and its future: security, stability, performance & usability (in its broadest sense, for developers, business cases, …). There’s still much to think about and discuss before we will publish more details, like the fee model: how do we enable the Hooks feature without allowing Hooks to be abused to spam the XRPL? Or: what is the Hooks environment going to look like (WebAssembly?). Did we cover all edge cases we can think of, and does the solution & implementation we ended up with support all use cases we initially thought of? Does the solution we come up with scale?

While we will spend more time brain crunching, designing & coding, we’re really excited we get to work & collaborate with awesome people & technology, in a world where we’re all able to contribute & share ideas, improving & contributing to the open and decentralized XRP ledger. While we still need some time, we are already really excited about engaging with you, devs & businesses, testing, integrating, and hopefully: seeing validators vote for our “Hooks” amendment (to be), at some point in the future.

Subscribe to live status updates (XUMM PHP SDK)

Wietse Wind — Thu, 24 Mar 2022 10:07:54 +0000

4. Subscribe to live status updates

So far, you've created a payment request, clicked the "next" URL, and scanned the QR code with you XUMM app to approve
or reject the request. Great!

As an app developer, you can subscribe to your payload's live status updates and react to them. For instance, you can
show the user who created the request a message that says "Payment request accepted! 🎉" when the user on the other end
has signed your request or "Payment request rejected :(️" when it was rejected.

Let's try and do that.

4.1 Create a callback function

One of the things that makes subscribing to status updates so powerful, is that you can pass it a callback function to
handle the data. The status update data will be passed to your callback as an instance of
Xrpl\XummSdkPhp\Subscription\CallbackParams.

Let's define your callback at the bottom of your script:

$callback = function(CallbackParams $event): ?array
{
    if (!isset($event->data['signed'])) {
        return null; // Don't do anything, wait for the next message.
    }

    if ($event->data['signed'] === true) {
        echo "🎉 Payment request accepted!\n";
        return $event->data;  // Returning a value ends the subscription.
    }

    echo "Payment request rejected :(\n";
    return [];
};

4.2 Start a subscription

Now let's start a subscription and pass our callback to handle any events that are coming in!

$subscription = $sdk->subscribe($createdPayload, $callback);

Now, when the user signs or rejects the request (which you can do by following the URL
as per the last step), your function will be called and the subscription ended.

4.3 Obtain a user token and send a push notification

Let's say that next time we send this user a sign request, we want them to receive a push notification on their phone.
We can do that by obtaining a user token for them and passing that into the next payload. The user token is issued when
they sign their first sign request. We just have to fetch the signed request using the event data we return in our
callback function.

Please note: this part uses Promises, which is a fairly new concept in
PHP. If you've written async code in JavaScript, you'll be familiar with it.

Let's wait until the subscription has ended, and then send ourselves another payment request. This time, we'll receive a
push notification on our phone because we pass the user token we've obtained.

$subscription->resolved()
    ->done(function (array $data) use ($sdk) {
        $payloadId = $data['payload_uuidv4'] ?? false;

        if (!$payloadId) {
            return null;
        }

        $signedRequest = $sdk->getPayload($data['payload_uuidv4']);

        $newRequest = $sdk->createPayload(new Payload(
            [
                'TransactionType' => 'Payment',
                'Destination' => 'rGBiHBoEs238W7H1b4gMey55He97kWcoUb', // Use your own address here
                'Amount' => '1000',
            ],
            $signedRequest->application->issuedUserToken,
        ));

        echo sprintf("The new request was %s\n", $newRequest->pushed ? 'pushed' : 'not pushed...');
    });

Be aware that to test this on your actual phone, you should have push notifications turned on for XUMM. It might also
help to put in a short sleep() statement before you push the new request, so you have some time to lock your phone and
clearly see the notification coming in.

Credits: thank you Pauline!

Your first payload (XUMM PHP SDK)

Wietse Wind — Thu, 24 Mar 2022 10:07:53 +0000

3. Your first payload

Now that we've established a connection to the XUMM platform using the SDK, it's time to send something we can sign.
We'll send a "transaction template" to the XUMM platform, called a Payload. The lifecycle of a Payload is explained in
more detail in the XUMM API documentation.

First, create a payload by instantiating an instance of Xrpl\XummSdkPhp\Payload\Payload. It must contain a
transaction body array formatted as per XRP ledger specifications. It can
contain a user token, options, and some custom metadata.

3.1 Create a payload

Our first payload will be a Payment transaction type. This is a very minimal example of a payload you can send to XUMM:

$payment = new Xrpl\XummSdkPhp\Payload\Payload(
    [
        'TransactionType' => 'Payment',
        'Destination' => 'rwietsevLFg8XSmG3bEZzFein1g8RBqWDZ', // Use your own address here
    ],
);

If, like in the minimal example above, no amount is entered, the end user will be able to select the currency and amount
to send in XUMM after opening the sign request. You could also add more details to your payload, as per the following
example:

$payment = new Payload(
    transactionBody: [
        'TransactionType' => 'Payment',
        'Destination' => 'rwietsevLFg8XSmG3bEZzFein1g8RBqWDZ', // Use your own address here
        'Amount' => '10000',
    ],
    options: new Options(
        immutable: true
    )
    customMeta: new CustomMeta(
        uniqid(),
        'Hi! Can you pay me please? Thanks! ❤️',
    )
);

3.2 Send the payload

Now you can pass your Payload object to XummSdk::createPayload and show the result:

$createdPayment = $sdk->createPayload($payment);
$url = $createdPayment->next->always;
echo "Sign request: ${url}\n";

Re-run your script to see it work! You can now follow the URL in the result and scan the QR code to sign the request,
or reject it.

The first time you send a user a sign request, they'll always have to scan the QR code. Once they've signed it, you can
obtain a user token for that user and send them push notifications on future sign requests! Let's see how that's done
in the next chapter:

Next: 4. Subscribe to live status updates

Credits: thank you Pauline!

Project setup (XUMM PHP SDK)

Wietse Wind — Thu, 24 Mar 2022 10:07:51 +0000

2. Project setup

Previous: 1. Create XUMM API credentials

The tutorial project has a little script that will use the SDK as a dependency. Right now, it returns a
Hello World response. Let's run it in our terminal:

php ./start.php   # Start server listening to port 8080

You should now see Hello World. Great! Any time you make changes to your project during this tutorial, you'll run the
script to see the changes.

2.1 Include the SDK

Use composer to add the XUMM PHP SDK as a dependency to your project:

composer require xrpl/xumm-sdk-php

2.2 Add your credentials

Note: this is the only part that won't be included in the code solution of this chapter, as everybody's credentials are
unique.

Assign the credentials you created in
Step 1
to the XUMM_API_KEY and XUMM_API_SECRET environment variables (be aware you need to do this on every new terminal
session):

export XUMM_API_KEY="{your API key}"
export XUMM_API_SECRET="{your API secret}"

2.3 Use the XUMM SDK

In start.php, include composer's autoload file at the top of the script, so that your script can find the XummSdk
class:

require_once './vendor/autoload.php';

Now instantiate the XummSdk. It will source your credentials from the environment variables you set in step 2.2.
To test the SDK, call XummSdk::ping and show the application name.

$sdk = new \Xrpl\XummSdkPhp\XummSdk();
$pong = $sdk->ping();
echo "Application name: " . $pong->application->name

Now when you run your script your should see:

Application name: {your app name}

🎉 It works!

Next: 3. Your first payload

Credits: thank you Pauline!

Using the XUMM PHP SDK (tutorial)

Wietse Wind — Thu, 24 Mar 2022 10:07:47 +0000

In a nutshell, the XUMM API allows developers to deliver sign requests
to their app's users, to create new transactions on the XRP ledger.

XUMM end users can then scan a QR code or receive a push notification to
open the sign request. When they approve it, XUMM signs it, and the transaction is placed on the ledger.

To make it easier to interact with the API, XUMM released an SDK in a number of languages,
most recently in PHP. This tutorial explains how to use it. Every chapter
will have a branch with the code solution in the tutorial's Git repository. So if you get stuck, just git checkout ch-2, git checkout ch-3, etc.

Prerequisites

For this tutorial, we assume you have:

basic knowledge of PHP and the terminal
composer installed on your machine
PHP^8.1 (the SDK's required PHP version) installed on your machine
the XUMM app on your phone, and an account
XUMM Developer credentials. You can register them at the XUMM Developer Console

Credits: thank you Pauline!

XUMM 1.1 » 2.0 » 3.0 - Update 🎉

Wietse Wind — Thu, 08 Apr 2021 11:44:04 +0000

Those who followed the recent developments at XPRL Labs, as Tweeted by XRPL Labs, XUMM & the XRPL Labs founder Wietse, know they can expect a significant XUMM update in the coming days.

tl;dr
 • XUMM 1.1 will be called 2.0 released in April 2021
     • This includes CSC migration support & tool
 • XUMM 2.0 will be 3.0, released in Q2~3 2021
 • We're introducing xApps, aggregating the XRPL ecosystem

Background

1.1: Not a 'dot one' release

The coming update has been referred to as "XUMM 1.1". The coming (soon) update did indeed started out as a 'dot one' release. However, while we were coding a couple of cool new features to add to the lastest (first public, final, non-beta) XUMM 1.0 release we decided to add a couple of significant new features to the 1.1 release we were already developing.

2.0: Profiles & opt-in KYC

Halfway last year ('20) we published our roadmap for XUMM, referring to a "XUMM 2.0" release around Q1 2021. XUMM 2.0 would introduce XUMM Pro, with 'opt in KYC', verified profile pages, hosted PayString, payment requests, transaction push notifications and some other cool features.

Vision: the ecosystem

While working on XUMM 1.1 features, our vision expanded. XUMM has the opportunity to do more than offer kick ass non custodial wallet features to end users. XUMM could (also) already empower developers to interact with end users (through 'sign requests', using the XUMM SDK).

Why not take the collaboration / integration between XUMM and the entire XRP Ledger ecosystem to the next level by allowing curated 3rd party XRPL ecosystem developers to put their own tools & XRPL apps straight into the hands of XUMM users?

What if XRPL ecosystem developers could build tools ('apps') then to offer them in a unified user interface inside XUMM? A great user experience for end users, while both users & developers don't have to worry about key management. XUMM takes care of security & signing.

Hi 'xApps' 👋 - "XRPL/XUMM Apps"

We figured developing exactly this would be win-win-win:

Other developers can offer their tools to end users in a secure, trusted environment: XUMM, without spending a single second on (private) key management.
End users get access to more on ledger features & tools, a better user experience (unified) & don't have to trust their keys to any other app.
More time for XRPL Labs to focus on core XUMM & XUMM Platform development, with more and more features being added to XUMM by trusted 3rd party developers.

We wrote drafts & coded some more.

Developing xApps

While adding xApp support to XUMM, we made a list of xApps to develop ourselves, using standard web technologies (HTML, CSS). To offer new features to end users & showcase xApps to users & developers. We came up with xApps to:

Configure Tangem Card back up cards
"Merge" on ledger accounts (AccountDelete)
Issue tokens on the XRPL
Create escrows
Trade (more advanced, limit orders) on the XRPL Decentralized Exchange (DEX)

(We have some more ideas, but with only 24 hours in a day we could only select a couple of them).

We realized some of the trusted, appreciated XRPL community developers built some of the tools on our list, like @nixerFFM's xumm.community, Towo Labs's XRP Toolkit and what about @Gatehub's awesome DEX trading interface? We pitched our xApps vision & invited them to build. And guess what? They did!

Welcome home CSC 🤗

Still working on XUMM 1.1, realizing that what we were working on would result in an update not worthy of a 'dot one' label, we were talking to a couple of familiar & respected people from the CSC (CasinoCoin) team. We talked about how their project, running on technology forked from the XRP Ledger, would benefit from migrating back onto the XRP Ledger.

In the years since their fork the XRP Ledger improved and advanced: it's more decentralized than ever, scalable infrastructure is being provided by multiple parties, new features are introduced and voted in by independent validators and with the upcoming Hooks amendment, smart contract features may even be available natively on the XRP Ledger in the future.

The cherry on top? XUMM would be available -out of the box- for the project's end users & partners. Offering a user friendly, secure & actively developed non custodial wallet & launchpad for CSC ecosystem xApps & online + retail integrations using xApps and the XUMM platform.

It didn't take much time for the CSC team to make a decision 😉. At XRPL Labs, we offered to build a token migration wizard. We could use our own technology to build it: a CSC migration xApp. Eating our own dogfood, our xApps implementation evolved and improved while we were building both the XUMM update & the xApp.

Planning & roadmap

Closing in on the end of our XUMM update development cycle, we realized that XUMM 1.1 actually became XUMM 2.0 - be it with different features (and quite some changes/updates under the hood making the implementation of our original planned 2.0 release easier to develop). We changed, fixed & added a total of 120 (!!) things. We updated the app, our platform, our infrastructure and our developer SDK. On top of that, we introduced, documented & built xApp support & our own xApps, and added a feature allowing XRPL forks to migrate back to the XRPL.

We feel our upcoming XUMM release kicks off a new chapter. Characterized by convergence & increased collaboration between XRPL ecosystem players, XRPL community developers and XUMM end users, with XUMM & the XRPL as the binding factor. We're aggregating the ecosystem.

@Arturo_P_A worded our own vision even better than we would have been able to do it ourselves:
// Detect dark theme var iframe = document.getElementById('tweet-1356574723434512386-776'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1356574723434512386&theme=dark" } // Detect dark theme var iframe = document.getElementById('tweet-1356585362395660291-231'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1356585362395660291&theme=dark" } // Detect dark theme var iframe = document.getElementById('tweet-1356587875610017792-888'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1356587875610017792&theme=dark" }

Changing version numbers

At the risk of confusing our users, we feel we must amend our version numbers & roadmap.

What we originally planned for a 2.0 release will be released ~mid 2021 in XUMM 3.0.

XUMM 3.0

Our ~mid 2021 XUMM release with features as originally presented in our mid 2020 blog post will be XUMM 3.0, featuring:

XUMM Pro (€50 / $60 per year)
Opt in KYC
Verified Profiles & Payment Request pages
Hosted PayString (previously called: PayID)
More (interesting) xApps, by XRPL Labs & other companies & developers from the XRPL ecosystem

A note on releasing xApps

xApps don't depend on a specific XUMM release version, so the can be published and updated on the go (rolling releases) without end users having to update their XUMM app. Expect us to do that (together with other XRPL devs). We'll be introducing new xApps between XUMM releases.

Exit 1.1, long live XUMM 2.0

Our upcoming XUMM release (April 2021) will be XUMM 2.0, featuring:

xApps
Dark mode
Payment requests (request XRP or fiat amount converted to XRP)
Currency rate conversion (XRP - fiat): secify fiat amount, send XRP equivalent
Improved (community provided) translations & more languages
Account re-ordering & hiding (eg. hide inactive Regular Key accounts)
Improved Decentralized Exchange transaction presentation in the transaction list (Events)
NFT support (XLS-14d)
Included xApps:
- Tangem card 'Back Up' (Regular Key)
- Account merge (AccountDelete)
- Escrow creator (by @nixerFFM)
- Token creator (issuer) (by @nixerFFM)
Importing alternative alphabet secrets & CSC Migration Wizard (with XUMM KYC)

We already developed a couple of important features required for XUMM 3.0: they are present (but hidden) in XUMM 2.0, so we can start testing XUMM 3.0 features with selected* (see note below) community members. This allows us to work our way towards a fast and smooth XUMM 3.0 release later this year.

We hope you understand we had to update our version numbering, and we're sorry for possible confusion we cause by doing so. Please allow us to make up for it with a boatload of improvements & awesome new features 😎

* Selected community members (early XUMM 3.0 feature (testing / beta) access are: well known XRPL ecosystem (development/business) contributors & all users who purchase(d) the XUMM Tangem 4 card or 5 card card pack, including "Early XUMM Pro Beta Access".

Hooked #5: Consensus

Wietse Wind — Fri, 05 Feb 2021 13:26:29 +0000

Please note

Since this blog was published a lot has happened. The Hooks Amendment is now running on a public testnet and has a public "Builder" where you (devs) can code Hooks and deploy them to the testnet, straight from your browser.

Warning: this is a highly technical blog 🤓 🤓 🤓

The Story So Far...

In Q4 of 2020 we released a Tech Preview of Hooks. This preview consisted of a docker container which would run a single instance of xrpld-hooks in stand-alone mode. As the name implies this was for the purpose of demonstrating how hooks will look in the future (without being a production-ready amendment.) Since then we have successfully replaced the web assembly runtime engine Wasmer with SSVM as part of a drive toward production grade efficiency. (See our previous blog.)

Testing Consensus

The 'stand-alone' mode of our Q4 2020 Tech Preview release meant that xrpld did not not communicate with other validators. It is a singular centralised validator simulating a decentralised ledger. This simulation is very useful for debugging and demonstrating behaviour, but achieving real consensus is very important. Without consensus the project can never produce live decentralised ledgers and therefore can never go into production on the live network. To begin tests of consensus we span up a two private testnet validators at our office.

At our first try everything worked as planned (🎉!) except for emitted transactions (that's fixed now). Emitted transactions are produced when a hook exercises its right to create new transactions separate to the triggering (original) transaction: for example the carbon hook emits a 1% payment to a carbon offset address every time the owner of the account sends a payment to someone. This is an emitted transaction.

Emission and Dispute

On our internal testnet the 'carbon hook' fired correctly on both validators and produced the same output. However a race condition emerged due to the way emitted transactions are queued for application to the next ledger.

Our initial strategy for emitting transactions was to insert the emitted transaction directly into the transaction queue, through xrpld's network interface, as though it were submitted by a special user.

One validator would always produce the emitted transaction slightly sooner than the other, and it would propose that transaction to the other validator. The other validator would not be able to find the transaction and would request a copy of it. The first validator would send a copy but the second validator would reject it and mark it as bad because emitted transactions cannot be received over the network (since they lack signatures this would be a massive security issue.)

As a result one validator would always have the emitted transaction and the other would never have it, therefore no consensus could be reached on emitted transactions.

Consensus Protocol to the Rescue

In most cases of consensus failure the answer is to use a consensus protocol to achieve agreement between otherwise disagreeing parties. Fortunately we don't need to reinvent the wheel here, xrpld already contains a consensus protocol called the Ripple Consensus Protocol.

To achieve consensus on emitted transactions we now emit them into a special directory on the ledger itself rather than emitting them directly into the transaction queue. This means all validators have a chance to produce and agree on what the emitted transactions indeed are before they attempt to queue them for application to a future ledger.

Now when a transaction triggers a hook which in turn emits a transaction, the validated triggering (originating) transaction's metadata looks like this:

The closed ledger looks like this:

Processing Emitted Transactions

To apply the emitted transactions to the next ledger xrpld-hooks reads the directory created above as soon as the last ledger closes, and injects those validly emitted and agreed upon transactions into the next ledger at the time it is created. This way, provided the validators achieved agreement on the last ledger they already have accepted the emitted transactions in the next ledger.

Common transaction fields have been modified to optionally include FirstLedgerSequence (as distinct from LastLedgerSequencewhich is already present in all transactions). FirstLedgerSequence is now mandatory on all emitted transactions. To begin with the field will always point to the next ledger (that is: the ledger after the ledger in which the transaction was emitted.) However in future it may be changed to allow a validator-votable figure. In short: this prevents emitted transactions being applied (executed) in the same ledger they were emitted, which could otherwise produce infinite loops (e.g. a hook emits a tx which triggers a hook which emits a tx etc.)

If FirstLedgerSequence is expanded it will allow validators to hold emitted transactions for future execution some specified number of ledgers later. This can be useful for on-chain bots, for example: Automated Market Makers which might need to periodically wake themselves up to do internal accounting even when they are not triggered by any external party.

Cleanup

The triggering (originating) transaction causes the emitted transaction to be added to the emission directory on the ledger. But once added that entry also needs to be removed or xrpld will continue to attempt to apply the same emitted transaction to every future ledger.

In xrpld ledgers are modified by transactions. It's not possible to just clean up the old emitted transactions. The modification of the ledger to delete the nodes associated with those emitted transactions in the emission directory needs to be caused by some transaction.

Fortunately we have a transaction: the emitted transaction! Every emitted transaction executes a callback to the hook that emitted it. This is important because without a callback the hook would have trouble knowing if its emitted transactions were eventually accepted by the network (and therefore whether or not, for example, a payment actually occured.)

Callbacks allow the hook to do internal accounting, modify its own state, and importantly now also automatically trigger a cleanup on the emission directory for that transaction. Callbacks cannot emit transactions or cause transactions to be rejected.

A validated emitted transaction now looks like this:

Calling all Hook Developers

Are you a developer interested in writing hooks? Would you like to share what you've built or ask questions?

Please check the other blogs, the source & README's and ... just a little more patience as we're on track for a Q1 public testnet release :)

Discussion

Discussions: here »

Next Steps

We are drawing close to public testnet. Some edge and corner cases still need to be debugged with emitted transactions, and the slot component of the Hooks API (which allows hooks to request and read all sorts of different data from the ledger) needs to be finished. We are well on track for a Q1 testnet release 🎉 😎

Photo by Paweł Czerwiński on Unsplash

Auto Reconnect(ing) OpenVPN client connections on EdgeOS

Wietse Wind — Fri, 29 Jan 2021 16:08:00 +0000

EdgeOS should automatically reconnect your OpenVPN client tunnel. If it doesn't, there are two things you can add to your OpenVPN client config that will make the client reconnect when it's down (eg. because the server or your internet connection has been down).

You can let your EdgeOS router ping over the VPN connection, and if it's down, reconnect it
Tell EdgeOS (OpenVPN client) not to store Auth Tokens, and always perform full auth after reconnecting.

Especially #2 is a problem for some, and hard to debug. You know this is happening if your log files show something like this:

grep "AUTH" /var/log/messages

Response:

messages:Month Day Time Hostname openvpn[id]: AUTH: Received control message: AUTH_FAILED

Let's add the ping setting to ping and auto-reconnect, and tell the EdgeOS OpenVPN client to ignore 'auth tokens' received (for a full re-auth on reconnect) assuming your OpenVPN client tunnel is vtun1. Then commit, save and exit.

configure
set interfaces openvpn vtun1 openvpn-option "--ping 10"
set interfaces openvpn vtun1 openvpn-option "--ping-restart 60"
set interfaces openvpn vtun1 openvpn-option "--pull-filter ignore auth-token"
commit; save; exit

Optionally you can add these settings to your .ovpn client config as well, without the prefixed double dash. Eg. edit your client .ovpn file, and add these lines to your client config:

ping 10
ping-restart 60
pull-filter ignore auth-token

Force Reconnect OpenVPN client connections (commandline) on EdgeOS

Wietse Wind — Fri, 29 Jan 2021 15:55:33 +0000

If your EdgeOS router has one or more OpenVPN client connections configured, you may want to restart the OpenVPN connection at some point. Either because it is down and somehow doesn't come back and you want to force that, or because you simply want it to restart (and pick up new settings / IP / ...).

In the EdgeOS web interface you can simply disable and re enable the VPN interface, but on the commandline it's not that easy.

Let's say your OpenVPN client connection is vtun1. To restart the connection the easy way, simply create (you can do this the easy way after installing the nano text editor)a script somewhere (eg. in /config/scripts. Let's call it restart-ovpn.sh.

The contents of the restart-ovpn.sh file (assuming your SSH client connection is vtun1) should be:

#!/bin/bash
/opt/vyatta/sbin/vyatta-cfg-cmd-wrapper begin
/opt/vyatta/sbin/vyatta-cfg-cmd-wrapper set interfaces openvpn vtun1 disable
/opt/vyatta/sbin/vyatta-cfg-cmd-wrapper commit
/opt/vyatta/sbin/vyatta-cfg-cmd-wrapper delete interfaces openvpn vtun1 disable
/opt/vyatta/sbin/vyatta-cfg-cmd-wrapper commit
/opt/vyatta/sbin/vyatta-cfg-cmd-wrapper end
logger -t piareset openvpn restarted

This scripts start a config session, disables the OpenVPN client, commits, deletes the disable flag, commits again, ends the config session and then writes a logline (for future reference).

You can now make the script executable:

chmod +x restart-ovpn.sh

... and the next time you want to restart your OpenVPN client connection on the commandline, simply run (from the folder where you created the restart-ovpn.sh file):

./restart-ovpn.sh

Reload BGP routes / configuration on your EdgeRouter

Wietse Wind — Fri, 29 Jan 2021 15:43:37 +0000

So you updated your BGP configuration and your EdgeRouter doesn't reflect your updates? Or the BGP service seems to have stopped and doesn't come back?

You run into this if you have BGP configured, but all show ip bgp commands return nothing, eg.:

show ip bgp summary

... results in just a newline and even stopping* & starting* the BGP service doesn't help.

A workaround is to save your existing config, delete the bgp settings, commit (that'll get EdgeOS to disable BGP), reload (load) your config (with BGP settings), commit (that'll get EdgeOS to restart EdgeOS with the most recent BGP config).

configure
save
delete protocol bgp
commit
load
commit
exit

*) Starting/Stopping the BGP service

When not in a configure session:

/etc/init.d/vyatta-quagga stop bgpd
/etc/init.d/vyatta-quagga start bgpd
# or:
/etc/init.d/vyatta-quagga force-reload bgpd

Enable key based SSH login to your EdgeRouter

Wietse Wind — Fri, 29 Jan 2021 15:37:08 +0000

If you want to login to your EdgeOS router using your SSH identity instead of a password, you can. Make sure you already have your SSH identity (key, pubkey). You'll need your pubkey later on to whitelist it in your EdgeOS config.

To configure SSH login using your your ssh key instead of a password, SSH into your EdgeRouter:

ssh {your-webinterface-username}@{your-router-ip} -p 22

Eg. ssh johndoe@192.168.1.1 -p 22

When logged in, start configuration mode:

configure

This tutorial assumes your username (to access the EdgeOS web interface (and SSH, just now)) is johndoe, replace johndoe with your actual username.

Now configure your SSH login key type:

set system login user johndoe authentication public-keys johndoe@device type ssh-rsa

Eg. set system login user myAdminAccount authentication public-keys myAdminAccount@myMacbook type ssh-rsa

Now add your public key. The value to add after key in the command below should be the Base64 string that's usually in your id_rsa.pub, without the ssh-rsa prefix, and without the hostname@device appended.

On OSX you can get this value using:
cat ~/.ssh/id_rsa.pub|cut -d " " -f 2

set system login user johndoe authentication public-keys johndoe@device key AAAAB.........

Now commit your settings:

commit

Open a second terminal window to check if you can sign in using your SSH identity, without a password. If everything works, you can save & exit:

save; exit

Done 🎉

Install `nano` on EdgeOS (2.x)

Wietse Wind — Fri, 29 Jan 2021 15:05:10 +0000

If you want to edit a (config) file on EdgeOS (2.X.X), you can. EdgeOS comes with vi. Not the easiest editor to get started with, especially if you just want to update a simple setting in eg. a OpenVPN client config file.

To make editing the occasional file a bit easier, you can install the nano package from the Debian repositories. To do that, SSH into your EdgeRouter:

ssh {your-webinterface-username}@{your-router-ip} -p 22

Eg. ssh johndoe@192.168.1.1 -p 22

When logged in, start configuration mode:

configure

Now set the Debian system package, by issuing these commands in the configuration mode:

set system package repository stretch components 'main contrib non-free' 
set system package repository stretch distribution stretch
set system package repository stretch url http://http.us.debian.org/debian

Apply the configuration by committing, save and exit:

commit; save; exit

Now update the system package cache:

sudo apt-get update

Do NOT upgrade system packages, that will break some of the packages your EdgeRouter depends on!

You can now install nano:

sudo apt-get install nano

Now nano is installed, we can remove the apt-cache, and remove the Debian repository again from the config:

sudo rm -R /var/lib/apt/lists
sudo rm -R /var/cache/apt/archives

Enter the configuration mode again, and remove the Debian system package repository:

configure
delete system package repository stretch
commit; save; exit

Forem: Wietse Wind

Hooked #0: Intro

Please note

XRPL Labs is working on the transaction "HOOKS" amendment for the XRP Ledger. Supporting business logic integration for developers.

Subscribe to live status updates (XUMM PHP SDK)

4. Subscribe to live status updates

4.1 Create a callback function

4.2 Start a subscription

4.3 Obtain a user token and send a push notification

Your first payload (XUMM PHP SDK)

3. Your first payload

3.1 Create a payload

3.2 Send the payload

Project setup (XUMM PHP SDK)

2. Project setup

2.1 Include the SDK

2.2 Add your credentials

2.3 Use the XUMM SDK

Using the XUMM PHP SDK (tutorial)

Prerequisites

XUMM 1.1 » 2.0 » 3.0 - Update 🎉

Background

1.1: Not a 'dot one' release

2.0: Profiles & opt-in KYC

Vision: the ecosystem

Hi 'xApps' 👋 - "XRPL/XUMM Apps"

Developing xApps

Welcome home CSC 🤗

Planning & roadmap

Changing version numbers

At the risk of confusing our users, we feel we must amend our version numbers & roadmap.

XUMM 3.0

A note on releasing xApps

Exit 1.1, long live XUMM 2.0

Hooked #5: Consensus

Please note

Warning: this is a highly technical blog 🤓 🤓 🤓

The Story So Far...

Testing Consensus

Emission and Dispute

Consensus Protocol to the Rescue

Processing Emitted Transactions

Cleanup

Calling all Hook Developers

Discussion

Next Steps

Auto Reconnect(ing) OpenVPN client connections on EdgeOS

Response:

Force Reconnect OpenVPN client connections (commandline) on EdgeOS

Reload BGP routes / configuration on your EdgeRouter

*) Starting/Stopping the BGP service

Enable key based SSH login to your EdgeRouter

Done 🎉

Install `nano` on EdgeOS (2.x)

Do NOT upgrade system packages, that will break some of the packages your EdgeRouter depends on!

Enjoy using nano for a quick config file edit :)

Enjoy using `nano` for a quick config file edit :)