😂 

 For that, best to ask the guy who build it nostr:nprofile1qqsq4hm8gawvch9y2m7nqghydaw4ym4s4a3gf0u9f9xqm4uy0ul9qvcpremhxue69uhkstnrdajxjmn8v9ex2mnp9e6x7up0da6hgcn00qq3vamnwvaz7tmwdaehgu3dwfjkccte9eshqup0qyghwumn8ghj7mn0wd68ytnhd9hx2tcht4zgq 

 To summarise briefly:
The election was not secret. Anyone can look up the events on the relays we use and check whether the respective nostr keys have also voted for the person in question.

The election was not yet super decentralised, as we only used our own internal relays because I was experimenting with two new event kinds. I would like to find out from real Nostr developers whether this was at all useful and whether someone can build a professional NIP or something similar from it. The storage format is also open to discussion. For the time being, I pragmatically used something that worked for me.

So we're talking more about a first proof of concept attempt to see how it works without email etc. In other words, we validate Nostr accounts and see whether it really is our active members who are signing Nostr events.

The whole issue of whether a Nostr key has been compromised is not yet part of this.

You will find the code here: https://github.com/HolgerHatGarKeineNode/einundzwanzig-nostr/blob/master/resources/views/pages/association/election/%5BElection%3Ayear%5D.blade.php

    $note->setKind($board ? 2121 : 32122);
    if (!$board) {
        $dTag = sprintf('%s,%s,%s', $this->currentPleb->pubkey, date('Y'), $type);
        $note->setTags([['d', $dTag]]);
    }

I have simply invented two new custom kinds. The president was a replaceable event 32122 and the confirmation of the board members was an event 2121.

I used simple ‘content’ to store which pubkey has voted how: $note->setContent(‘$pubkey,$type’);

This can be rubbish and would be better packaged professionally in a NIP design.

I'm not sure how to do this ‘properly’ with a NIP.
 

 nice. I thought of 3 ways you could improve secrecy, but they all add some centralization:
1- gift wrap the vote events, so only the person doing the tally could read them. In that case you must trust the person or group doing the tally to be honest.
2- You could use a group of independent persons to do the tally, and distribute the key to them, so they would check on each other.
3- You could publish the private key after the end of the election, so anyone can verify (but then the votes are only secret until the key is published)

I have no experience writing a NIP, but i can help polishing it if you ever need help. 

 Stell dir Amber oder Getalby eher als Kondom für deinen nsec vor. Du kannst auch deinen nsec direkt raw ins Portal eingeben und abstimmen, aber solche apps wie amber sind dafür da, dass du nur events signierst ohne deinen private key im Portal zu hinterlegen. 

 Nsec direkt eingeben geht tatsächlich nicht. Das wäre zu unsicher. Es geht NSEC.APP dort liegt es dann im local storage deines Browsers. Aber morgen im Detail mehrm liege schon im Bett :)

Amber und Co fungieren als Signatur-App, also genau wie auch Software Bitcoin Wallets funktionieren. 

 Um es nochmal zusammenzufassen:

Amber auf Android als Signier-Software für seine Nostr-Keys zu verwenden und sein nsec nirgends mehr in andere Software oder Clients einzugeben ist genau die bitcoin-art.

Amethyst unterstützt das bunker:// Protokoll. Also brauchen wir auch nicht mehr dort unser nsec einfach so blank eingeben.

Andere Clients ziehen nach und auch dort ist Nostr-Connect mit Amber dann möglich.

iOS-User schauen mal wieder in die Privatsphäre-Röhre. Die könnten aber so etwas wie nsec.app benutzen, welches dein nsec im lokalen Storage des Browsers hält, um dann über das bunker:// Protokoll Events zu signieren.

Also Ziel ist es so gut es geht, nur noch eine Applikation als Signier-Software und in Zukunft noch besser sogar Hardware-Signatur-Geräte, für Nostr zu verwenden.

Die Amber Software kann hier selbst kompiliert und geprüft werden: https://github.com/greenart7c3/Amber 
 

 Wow, vielen Dank für die ausführliche Erklärung :-)