pak bych tu měl jeden tip Aplikaci Joplin používám už docela dost dlouho a funguje naprosto skvěle. Rozhodně bych ji dal alespoň šanci. K dalším vychytávkám, které jsem si oblíbil a používám jsou například profily, import/export všemožných formátů, nebo pokud budete používat nativní Joplin server pro synchronizaci (ať už selfhosted, nebo hosted u autora), můžete poznámku i veřejně publikovat. Díky @archos@mastodon.arch-linux.cz a Oscloud.cz pak může nasdílet svoji poznámku komukoli. Možnost zašifrování synchronizovaných poznámek je samozřejmostí.

A pokud jde o hostování Joplin serveru a nechcete zaplatit pár korun autorovi, ale rádi byste si funkce serveru vyzkoušeli a nemáte možnosti nebo znalosti hostovat vlastní, můžete požádat na Oscloud.cz o účet zdarma. Za mě palec nahoru za to, co dělají a pokud byste byli spokojeni, bylo by fajn, jim na provoz nějakou tou korunou i přispět.

Co potřebuji?

1) LNURLp

Ten první krok – automatické vygenerování faktury – za nás už vyřešilo LNURL a jeho konkrétní varianta LNURpayRequest, (někdy také LNURLp).

Co to je?

Jedná se v podstatě o zakódovanou URL adresu, kde se klient (peněženka) dozví, základní informace o tom, kolik minimálně a maximálně může zaplatit, nějaké ty metainformace, kde najde potvrzení, nějakou zprávu, a hlavně na jakou URL adresu má požádat o vytvoření nové LN faktury na konkrétní částku, která pak může být zaplacena.

Takhle nějak to vypadá ten proces komunikace:

Tak to je skvělé! Není nad automatizaci. Namísto celé dlouhé faktury, kterou musí člověk vytvořit, už nám stačí jen jedna URL do nekonečna a na částce, faktuře ke zaplacení, a případně dalších věcech ať se domluví stroje spolu sami, mě stačí bitcoiny.

Kde to seženu?

Je potřeba mít peněženku, která ji podporuje a umí nějakou funkční vygenerovat. Je to poměrně rozšířený standard, a pokud vám na vygenerovanou LNURL půjde zaplatit, pak vám bude fungovat i platba přes email na vaší doméně díky překladu LN adresy popsanému dále. Pro vlastní hostované řešení, je pravděpodobně nejpoužívanější LNBits.

2) Webový server obsluhující Vaši doménu

Pro překlad LN adresy ve formě emailu budeme potřebovat webový server, na který pak půjde požadavek po zadání LN adresy v peněžence. Za tímto účelem jsem si vypůjčil přehlednou grafiku z dokumentace lighting-address, jak samotný překlad na URL vypadá a která podle mě víc vysvětlení nepotřebuje.

Skvělé, to všechno už mám... jak to ale slepit?

Tak hurá na to. Jako první musíme dekódovat LNURL na reálnou URL, na kterou budeme přeposílat klienty jdoucí naši LN adresu (respektive na .well-known/.... URL).

Dekódování LNURL

Budeme potřebovat rozklíčovat, na jakou URL vlastně vede naše LNURL adresa. Je to adresa, která po dotázání vrátí základní podrobnosti o platbě v podobě LNURL Pay JSONu. V dokumentaci se můžeme dočíst, že jde o zakódování URL pomocí bech32 a je tam i ukázka kódu v Scala a JavaScriptu. Nejjednodužší je prostě copy/pasta buď do nějakého online nástroje pro testovaní, například JSFiddle (javascript) nebo Scastie (nicméně bývají problém s přímým importem), nebo využít vlastní dev/IDE prostředí. Já osobně jsem si to nechal pomocí AI přepsat do Pythonu, který už mám nainstalovaný a bylo to pro mě nejjednodužší řešení a hned po pár iteracích jsem se dopracoval až tomuto kódu:

# python3
import bech32
import sys

def decode_lnurl(url):
    """
    Decodes a bech32 encoded LNURL string.

    Args:
        url (str): The bech32 encoded LNURL.

    Returns:
        str: The decoded URL.
    """
    # The 'bech32_decode' function correctly handles the full bech32 string.
    # It returns the human-readable part (hrp) and the data part as 5-bit integers.
    hrp, data = bech32.bech32_decode(url)
    if data is None:
        raise ValueError("Invalid bech32 string")

    # The 'convertbits' function converts from 5-bit data to 8-bit data.
    decoded_bytes = bech32.convertbits(data, 5, 8, False)

    # The resulting bytes are then decoded into a UTF-8 string.
    return bytes(decoded_bytes).decode('utf-8')

# --- Main execution block ---
if __name__ == "__main__":
    # sys.argv is a list of command-line arguments.
    # sys.argv[0] is the script name itself.
    # sys.argv[1] is the first argument.
    if len(sys.argv) < 2:
        print("Usage: python your_script_name.py <bech32_encoded_url>", file=sys.stderr)
        # Exit with a non-zero status code to indicate an error
        sys.exit(1)

    # Get the LNURL from the first command-line argument
    bech32lnurl = sys.argv[1]

    try:
        # It's good practice to uppercase the input as bech32 is case-insensitive
        # but decoders often expect uppercase for validation.
        decoded_url = decode_lnurl(bech32lnurl.upper())
        print(f"Decoded URL: {decoded_url}")
    except (ValueError, TypeError) as e:
        print(f"Error decoding LNURL: {e}", file=sys.stderr)
        sys.exit(1)

pak už jen stačilo nainstalovat bech32 modul, dát jako parametr zakódovanou LNURL a vyplivlo mi to, co jsem potřeboval.

python3 -m venv bech32
source bech32/bin/activate
python3 -m pip install bech32
python3 bech32encode.py "LNURL1DP68GURN8GHJ7UM9WFMXJCM99E3K7MF0V9CXJ0M385EKVCENXC6R2C35XVUKXEFCV5MKVV34X5EKZD3EV56NYD3HXQURZEPEXEJXXEPNXSCRVWFNV9NXZCN9XQ6XYEFHVGCXXCMYXYMNSERXFQ5FNS"

Decoded URL: https://service.com/api?q=3fc3645b439ce8e7f2553a69e5267081d96dcd340693afabe04be7b0ccd178df

NOTE: Pokud by jste chtěli nahlédnout na LN fakturu, LNURL JSON, ale bez těch “tanečků” okolo, můžete použít Lighting decoder.

Nastavení HTTP serveru

Tady je situace asi nejsložitější, protože zavisí na způsobu řešení. Pokud sami hostujete službu poskytující LNURL endpoint (např. LNBits), pravděpodobně vám bude stačit přidat už jen rewrite pravidlo pro danou korektní LNURL:

<VirtualHost *:443>
    ServerName domain.com
    # SSL konfigurace
    SSLEngine on
    #....
    
    # Proxy pro /lnurlp requests na backend server
    ProxyPreserveHost On
    ProxyPass /lnurlp/ http://10.1.1.2:5000/lnurlp/
    ProxyPassReverse /lnurlp/ http://10.1.1.2:5000/lnurlp/
    
    # Rewrite pravidlo pro Lightning address
    RewriteEngine On
    RewriteRule ^/\.well-known/lnurlp/username$ /lnurlp/3fc3645b439ce8e7f2553a69e5267081d96dcd340693afabe04be7b0ccd178df [L]
    #....
</VirtualHost>

Pokud jde o LNURL třetí strany, použije se přímý redirect na danou dekódovanou URL:

<VirtualHost *:443>
	ServerName domain.com
	# ...
	# Redirect pravidlo pro Lightning address - přesměruje na API endpoint
    RewriteEngine On
    RewriteRule ^/\.well-known/lnurlp/username$ https://service.com/api?q=3fc3645b439ce8e7f2553a69e5267081d96dcd340693afabe04be7b0ccd178df [R=302,L]
	# Alternativně, presmeruj "bitlifi@domain.com na wallet u bitlifi na tel. cislo do 90-tek.
	RewriteRule ^/\.well-known/lnurlp/bitlifi$ https://bitlifi.com/.well-known/lnurlp/420609112567 [R=302,L]
    # ...
</VirtualHost>

V extrémním případě je možné vrátit i ručně editovany JSON soubor. Určitě to není ideální, ale funguje to, pokud bude endpointURL dostupná a souhlasit atributy očekávané faktury.

S přepisem do jiných webových serverů případně může pomoci AI.

Testování

Nejjednodušší je prostě zkusit curl na náš nový rewrite:

curl -s https://domain.com/.well-known/lnurlp/username

# někdy je potřeba si explicitně vyžádat JSON, 
# například v případě Bitlifi nebo Wallet of Satoshi
curl -s -X GET \
-H "Accept: application/json" \
-H "Content-type: application/json" \
https://bitlifi.com/.well-known/lnurlp/<TELEFONICISLO>

# pro hezky formátovaný JSON se dá využít pipe do jq:
curl -s -X GET \
-H "Accept: application/json" \
-H "Content-type: application/json" \
https://bitlifi.com/.well-known/lnurlp/<TELEFONICISLO> | jq -r

a v idelaním případě bychom měli dostat odpověd podobnou tomuto JSON formátu (mohou tam být i políčka navíc, záleží na implementovaných specifikacích)

{
  "tag": "payRequest",
  "callback": "https://service.com/lnurlp/api/v1/lnurl/cb/3fc3645b439ce8e7f2553a69e5267081d96dcd340693afabe04be7b0ccd178df",
  "minSendable": 1000,
  "maxSendable": 100000,
  "metadata": "[[\"text/plain\", \"Platba\"], [\"text/identifier\", \"username@domain.com\"]]",
  "commentAllowed": 300
}

netcat -vz portquiz.net 1-9999 2>&1 | grep -v failed

Reference: https://superuser.com/questions/577206/how-can-i-check-what-outbound-ports-are-allowed-in-a-network

1) Create user, you are planning to use within container and ged it's UID

root@synology:~/# id c-emby
uid=1032(c-emby) gid=100(users) groups=100(users),65538(docker),65537(video)

2) Get GID of “video” group (should be group owner of /dev/dri/* devices)

root@synology:~/# ls -la /dev/dri
total 0
crw-rw----  1 root video 226,   0 Sep 26 11:54 card0
crw-rw----  1 root video 226,  64 Sep 26 11:54 controlD64
crw-rw----  1 root video 226, 128 Sep 26 11:54 renderD128

root@synology:~/panelacek/conf-scripts/docker# grep video /etc/group
video:x:65537:root,docker,c-emby

3) Download container image and configure container with proper UUID / GUID and GIDLIST variables. One of GIDLIST needs to be GID of “video” group

UID=1032 //container user UID (c-emby)
GID=65538 //contaner group GID (docker)
GIDLIST=65538,65537 //docker,video

4) Map video devices to container

--device /dev/dri/card0:/dev/dri/card0 \
--device /dev/dri/controlD64:/dev/dri/controlD64 \
--device /dev/dri/renderD128:/dev/dri/renderD128 \

whole emby-docker-server.sh script (downloads and refresh emby server)w:

#!bin/sh
NAME="embyserver"
IMAGE="emby/embyserver:latest"
docker pull ${IMAGE}
docker stop ${NAME}
docker rm ${NAME}
docker run -d \
--name=${NAME} \
-e UID=1032 \
-e GID=65538 \
-e GIDLIST=100,65538,65537 \
-e TZ=Europe/Prague \
-p 32775:8096 \
-p 32768:8920 \
--privileged \
--device /dev/dri/card0:/dev/dri/card0 \
--device /dev/dri/controlD64:/dev/dri/controlD64 \
--device /dev/dri/renderD128:/dev/dri/renderD128 \
-v /volume1/docker/Emby:/config:rw \
-v /volume1/Movies:/movies:rw \
--restart unless-stopped \
--memory=4g \
--cpu-shares=90 \
${IMAGE}

Klasický scénář – dálkový ovladač po letech začne zlobit, takže je na čase vyměnit baterie. No, a po výměně ejhle – dálkové odemykání nefunguje. Je to vcelku známý problém, po výměně baterie je někdy potřeba klíč zesynchronizovat (naprogramovat). Možnosti jsou dvě – pomocí VAG nebo pomocí speciálního postupu v autě. A protože VAG nemám, probereme si tu variantu pomocí speciálního postupu.

Jako první doporučuji ověřit, zda klíče vůbec vysílají signál. Já poměrně hodně času zabil jen tím, že jsem zkoušel synchronizovat nefungující klíč. Respektive byl nějaký zmatený. Musel jsem jej asi 6× rozebrat a složit, než začal vůbec fungovat správně (nejdříve byly kontakty vyhnuté kvůli nafouknuté původní vybité baterii, takže nefungoval vůbec. Pak klíč zase, pro změnu, generoval signál na jiné frekvenci). Každopádně poslední (asi 6.) rozborka klíče a pořádné vyčištění už pomohlo.

Ověření funkčnosti klíče

Klíče vysílají na frekvenci 433,910 MHz a možnosti kontroly jsou v zásadě dvě. Vysílačka/scanner (například Baofeng UV-5R za cca 500 Kč), který umožňuje nastavit danou frekvenci, nebo zakoupit DVB-T dongle s čipsetem RTL 2832 (cca 200 Kč), který je možné pak připojit k telefonu (OTG kabel) a scanovat frekvence pomocí SDR Touch aplikace.

Pokud zmáčknete tlačítko ovladače, ve vysílačce nebo spektrálním analyzéru uslyšíte (uvidíte) výrazný signál. Pokud to “něco dělá”, máte vyhráno.

Nakódování (synchronizace) klíče

Prošel jsem hodně návodů a zkoušel hodně možností. Nakonec ověřená fungující varianta byla:

1. Vložit klíč do zapalování
2. Otočit do rozsvícení kontrolek
3. Zmáčknout a držet tlačítko zamčení na klíči a zároveň zamknout v autě pomocí tlačítka na dveřích
4. Stejným způsobem odemknout – držet tlačítko odemknutí a odemknout vypínačem na dveřích
5. Vypnout zapalování a vytáhnout klíček

Pak by mělo odemykání a zamykání zase fungovat. Je dost možné, že bude fungovat jen pomačkání tlačítek (bez zamykání na dveřích), ale tohle mám ověřené, tak můžete zkusit, ale mě fungovalo toto.