metsonet

Verifying signatures on the XRPL with Python

Sat, 23 Oct 2021 00:00:00 +0100

Writing this more because I spent a while bouncing around the internet trying to find an example. There’s a nice library for Javascript from the good people at XRP Labs but I couldn’t find similar in Python, and needed to verify a signature for a XUMM login. There is a comprehensive Python SDK so I figured rolling my own wouldn’t be a hardship. In fact it was super easy, the whole thing is just two functions, it was just a bit hidden away in the docs.

What’s nice is we can use the example from the javascript tool to confirm:

from xrpl.core.binarycodec import decode
from xrpl.core.binarycodec import encode_for_signing
from xrpl.core.keypairs import is_valid_message


transaction_hex = '2280000000240000000268400000000000000C73210333C718C9CB716E0575454F4A343D46B284ED51151B9C7383524B82C10B262095744730450221009A4D99017F8FD6881D888047E2F9F90C068C09EC9308BC8526116B539D6DD44102207FAA7E8756F67FE7EE1A88884F120A00A8EC37E7D3E5ED3E02FEA7B1D97AA05581146C0994D3FCB140CAB36BAE9465137448883FA487'

decoded = decode(transaction_hex)

expected_account = 'rwiETSee2wMz3SBnAG8hkMsCgvGy9LWbZ1'
assert decoded['Account'] == expected_account

is_valid_message(
    bytes.fromhex(encode_for_signing(decoded)),
    bytes.fromhex(decoded['TxnSignature']),
    decoded['SigningPubKey'],
)

It seemed to make sense to wrap this up into a helper library and open source it. Let me know if you see any mistakes!

Some nice music from Audiotarky

Sat, 27 Feb 2021 00:00:00 +0000

Just testing something for Audiotarky.

Some more nice music from Audiotarky

Sat, 27 Feb 2021 00:00:00 +0000

Just testing something else for Audiotarky.

These are my racks

Tue, 12 Jan 2021 00:00:00 +0000

Partly due to recording with Anechoics and partly due to lockdown boredoms I’ve been updating my modular grid entries. I’m starting to admit that I possibly have a problem… It’s so bad that I’ve added a Jekyll include especially for modular grid images. Winning!

In general I’ve tried to make the racks be independently useful/complete. They’ll have control modules (sequencers, switches, clocks…) and voice modules (VCO’s, VCA’s, envelope generators) so that they could be used on their own, or linked up to make something larger.

Little guy

Built in my first case from Pittsburgh modular, this has housed my Metropolis for almost forever.

Hack rack voices 1

Built in a box from Ikea I’ve enjoyed building these “hack racks”, to the point of doing it for fun… Lots of different VCO’s in here, but they kind of make sense together, especially the two Doepfer A-110-4 SE, which I use to FM one another. Filthy.

Hack rack voices 2

This one is still a WIP - I need to finish the uO_C - and it’s a bit of a weird rack. Kind of for drones, loops, and other weirdness, but with a really nice VCO at it’s centre (the Tš-L v2).

Hack rack brains

This was called “brains” when it had a few more logic and sequencer modules in, but the name has stuck. That said, it has two very nice, and slightly unusual sequencers in (the Antumbra Rot8 and the Division 6). While its not got a lot of voices in, the Sloth & WPO is probably one of my favourite voice combos. The blank panels are actually a switched mult and a Tape Sampler from my friend Jack.

Big guy

This is my biggest synth, which is sort of a problem. It’s so big that I don’t use it enough - it probably needs a rethink. It’s built out of recycled parquet flooring that I got from the Bristol Wood Recycling Project (a happy place…) which is a sort of great & sort of terrible material to build a synth from. It also lacks finesse as I lack a workshop.

My Unsafe Eurorack

Built in a Thomann rack enclosure, this was the first case I wired up with a Meanwell PSU. It’s got some of my favourite modules (Rampage, Ryk M-185, Sampleslicer) in and probably more buffered mults than it needs.

(for some reason MG isn’t rendering this one right yet… best to click through to see it in all its glory…)

Office music with Mopidy

Fri, 06 Nov 2020 00:00:00 +0000

Since lockdown began in March (it was March, wasn’t it?) I’ve been working from home. This took a while to get used to - my short drive to/from the office put my brain in gear - but is now “the new normal”.

One of the little benefits of working from home is that I can listen to music more. I don’t much like wearing headphones, especially not all day, so when in the office I don’t usually listen to music. But at home I have a stereo and can put on tunes to my hearts content (currently listening to Bill Callahan’s “Gold Record”).

I have tried a few variations on the theme of “Spotify going into the stereo”, using either an old Mac Mini or plugging in my phone. During lockdown (I forget when…) I switched things up a bit and got a raspberry pi 4 to work as my music source. This runs Mopidy and the Iris UI.

Mopidy plays music from local disk, Spotify, SoundCloud, TuneIn, and more. You can edit the playlist from any phone, tablet, or computer using a variety of MPD and web clients

The pi is a great piece of kit, and Mopidy is a nicely written bit of software that’s easily installed and configured. It means I can line up tracks, “discover” them etc. and just have a nice stream of music coming into my earholes. I have vague hopes of plumbing in Audiotarky one day.

I’ve had to prod Alsa a few times, it seems a recent update (or possibly me plugging something in differently) has made the soundcard device move around a bit. Not to worry, this can be configured in /etc/asound.conf.

First find the device you want to use with sudo aplay -l:

$ sudo aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: b1 [bcm2835 HDMI 1], device 0: bcm2835 HDMI 1 [bcm2835 HDMI 1]
  Subdevices: 4/4
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
  Subdevice #2: subdevice #2
  Subdevice #3: subdevice #3
card 1: b2 [bcm2835 HDMI 2], device 0: bcm2835 HDMI 2 [bcm2835 HDMI 2]
  Subdevices: 2/2
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
card 2: Headphones [bcm2835 Headphones], device 0: bcm2835 Headphones [bcm2835 Headphones]
  Subdevices: 1/2
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
card 3: sndrpihifiberry [snd_rpi_hifiberry_dac], device 0: HifiBerry DAC HiFi pcm5102a-hifi-0 [HifiBerry DAC HiFi pcm5102a-hifi-0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

I want to use the Headphones device, so my /etc/asound looks like:

pcm.!default {
       type hw
       card Headphones
}

ctl.!default {
        type hw
        card Headphones
}

Once configured, you can verify with aplay /usr/share/sounds/alsa/Front_Center.wav.

Once you’ve got the config how you want, restart mopidy:

sudo systemctl restart mopidy
sudo systemctl status mopidy

Audiotarky announced!

Tue, 06 Oct 2020 00:00:00 +0100

Hugely chuffed to be awarded a grant for the web to build on some of the web monetisation/music streaming I’ve been doing over the summar. More info on the new Audiotarky blog.

Tekton aide-mémoire

Fri, 02 Oct 2020 00:00:00 +0100

I’ve been doing some work on Tekton this morning, dusting off somethings I did back in April. One thing that I wrote down at the time but now can’t find (grumble) is how I got a local instance running on minikube, so I thought I’d put it here for posterity.

minikube start

# Clean install
kubectl delete namespace tekton-pipelines
kubectl delete deployment -n tekton-pipelines tekton-dashboard

# Install tekton & its dashboard
kubectl apply -f https://storage.googleapis.com/tekton-releases/latest/release.yaml
kubectl apply --filename https://storage.googleapis.com/tekton-releases/dashboard/latest/tekton-dashboard-release.yaml

# Verify (ctrl-c to get out)                     
kubectl get pods --namespace tekton-pipelines --watch

# Access via port forwarding
kubectl --namespace tekton-pipelines port-forward svc/tekton-dashboard 9097:9097

This gets to a working tekton dashboard accessible at localhost:9097.

You can then push resources in via kubectl apply -f pipeline.yaml etc.

Theres a tekton CLI now (at least, I don’t think it was there when I last used it) which can be installed via brew, I also had an old minikube, so updated via:

brew install tektoncd-cli
brew install minikube
brew upgrade minikube

Some helpful blogs:

Panel template helper

Wed, 23 Sep 2020 00:00:00 +0100

Inspired by the Music Thing Modular workshop notebook and an Ikea notebook I’ve started a simple SDIY template, that folds into three panes. At the moment it has:

2, 3, 4, 8 & 16 HP panel sizes (might add 6 & 10HP)
Thonkiconn footprint in four orientations
IC pin out for 555 timers, TL072 & TL074 chips
A simple 56 HP tape measure

I quite like the iea of it being a double sided guide, so I’m wondering what else to put on it. Things like resistor values seem obvious but less useful, especially for panel design. Knob sizes might be useful, but I think laying out some knobs on the paper would be more useful (though perhaps less practical for coffee shop designing). More IC’s would be good, but which? Pots? Sliders? Switches? Suggestions welcome.

Feeling twitchy

Thu, 17 Sep 2020 00:00:00 +0100

This week I’ve made not one but two Twitch appearances with Matt. The first was starting to code up a ML/AI to identify synth modules. The idea for this came to me when I thought about updating my modulargrid page & realised I’ve got enough bits & pieces that it would be a chore. I’m lazy & we live in the future, so surely a robot could do it for me!

Well, one can’t, yet, but Matt & I will be making one over the coming weeks. So far we’ve got the tooling to make a training dataset (you can see the code here). We’d planned to use a tool that was down at the time of recording, so hastily had to rethink our approach, which led to some mildly panicked coding behind the scenes. I think Matt covered it excellently, though, and did a good job of turning a problem in to a way to explain things to the audience.

The second appearance happened this morning. Matt spotted a GitHub hackathon which our previous twitchings seemed like a good starting point to build upon. I could only join for the first 30 mins (real life got in the way) but when I dropped we had the bare bones of the action set up and I left Matt to “draw the rest of the owl”. Which he duly did.

I did! :)

Wooohooo!!!! pic.twitter.com/pikwh54qJc
— Matt Hamilton (@HammerToe) September 17, 2020

I have to say, he seems very surprised that it works! ;)

You can watch the full stream below.

Embeddable playlists & the ILP jailbreak

Mon, 07 Sep 2020 00:00:00 +0100

I’ve been building a web monetized music platform, in my copious spare time. You may have even heard some of it. One thing I added a while back to this site is a playlist, built from all the posts that have direct link to a track, as opposed to one hosted on Bandcamp, Soundcloud or Spotify. That was nice, and it does a couple of cute things:

auto-generated from music posts that use audio files hosted on this site, linking to those pages
changes artwork with the tracks
can “pop out” into its own window
prompts about Coil if not enabled

The next thing I wanted to do with it was have it be embedable, such that someone could put the playlist on their own page. Doing that with a simple <iframe> is easy enough, but there’s a sticking point. The whole point of this is to have the music be web monetized, and Coil’s plugin (quite reasonably) blocks an <iframe> from requesting payment - I suspect because if this wasn’t the case, one page could end up with hundreds of streams of payment, which would make everything complicated. This could make it easier for people to hijack payments, too.

So, this got me thinking. I wanted a simple (as in few character long) embed code that people could use (Bandcamp et. al use <iframe>), but also have the content set the ILP for the track playing, which means having a way to “jailbreak” the ILP pointer out of the <iframe>. Instead of a simple <iframe>, could this be done with a <script> (spoiler; yes, yes it could).

The solution is in two parts; the playlist & the embed script. The playlist page needs to be aware that it might be placed in an <iframe>, and if it is it needs to communicate the ILP for the track that’s playing to its parent. This can be done via the postMessage API, the relevant bit of code for this site is:

function sendILPToParent(ilp){
    if ( window.location !== window.parent.location ) {
        var data = {"playlist-ilp": ilp};
        parent.postMessage(data, "*");
    }
}

This checks to see if the page is in an <iframe>, and if it is sends the ILP via postMessage to the parent. Neat-o.

Now we need something on the other side. The script is pretty short, and I think fairly self explainatory. The relevant bit for the “jailbreak” is:

window.addEventListener("message", function (event) {
    const ilp = event.data["playlist-ilp"] || false;
    if (ilp) {
        var not_done = true;
        const metas = document.getElementsByTagName('meta');
        for (let i = 0; i < metas.length; i++) {
            if (metas[i].getAttribute('name') === 'monetization') {
                metas[i].content = ilp;
                not_done = false;
                console.log("set ilp to " + ilp + " via event.");
            }
        }
        if (not_done) {
            const monetizationTag = document.createElement('meta');
            monetizationTag.name = 'monetization';
            monetizationTag.content = ilp;
            document.head.appendChild(monetizationTag);
            console.log("added meta & set ilp to " + ilp + " via event.");
        }
    }
});

This listens for a message event, and on receiving one, proceeds to either update the monetization <meta> tag, or create one. What’s nice is, because this is event based, when the track changes this can be invoked again, updating where the micropayments flow. You can see this in action here and over on the Anechoics site - notably that’s pulling in the script, playlist, music & images from another domain.

The script is configurable, on the embedding side, and those configurations are pulled out by the script via code like document.currentScript.getAttribute('playlist');. This means people could embed different playlists, configure size or styling etc. as they embed the music.

What’s nice with this two part solution is that the <iframe> doesn’t dictate what happens in the parent, it just sends up a message that the parent gets to choose what to do with. This prevents hijacking payments, to some extent. It also means that the embeded playlist is suitably decoupled from the parent - it just needs to send that message to route payments and otherwise focus on playing music.