ccoors

Reduzieren des Power Levels von Puppet-Benutzern von Matrix-Bridges

2025-06-17T00:00:00Z

Ich bin momentan Mitglied der AG Administration im Hackerspace Bremen. Wir betreiben für unsere Mitglieder:innen einen föderierten Matrix-Homeserver. Dieser Dienst ist noch relativ neu, und wir nutzen die mautrix-discord Bridge mit “double puppeting” um einige Räume eines legacy Discord-Servers nach Matrix zu bridgen, sodass User, die noch nicht auf Matrix umgestiegen sind weiterhin die Möglichkeit haben, an unseren Chats teilzunehmen. Die Bridge erzeugt für alle Discord-Benutzer im Matrix “Puppet-User” und leitet Nachrichten in beide Richtungen entsprechend weiter.

Versehentlich hatte ich einem dieser Puppet-User einen Power Level von 100 in einem der Matrix-Räume gegeben. In Matrix erreicht man eine Patt-Situation, sobald man mit einem anderen Benutzer auf demselben Power Level steht. Die Benutzer können sich die Berechtigung nicht mehr gegenseitig enziehen, nur noch sich selber und Benutzern mit niedrigerem Power Level.

Die Vergabe dieser Berechtigung an einen Puppet-User hat zwar keine unmittelbar negativen Folgen, der Zustand hat mich jedoch nicht glücklich gemacht und ich suchte nach Möglichkeiten, meinen Fehler rückgängig zu machen. Glücklicherweise war Tulir durch den Verweis auf das Matrix Application Service API im Support-Raum #discord:maunium.net sehr hilfreich. Mit dem Access Token der Bridge selber können im Namen aller Puppet-User Events verschickt werden.

Es ist natürlich möglich, von Hand eigene curl-Aufrufe zu konstruieren, ich habe aber etwas besser reproduzierbares mit mautrix-python (auch von Tulir) ausprobiert. Hier nun die Befehle, die am Ende zum Erfolg geführt haben.

Nach der Installation des Paketes eine asyncio Shell öffnen (python -m asyncio) und diese Befehle ausführen, um ein ClientAPI-Objekt zu erzeugen. Die Werte nach Bedarf anpassen:

>>> from mautrix.client import ClientAPI
>>> puppet_user = "@discord_...:hackerspace-bremen.de"
>>> base_url = "https://matrix.hackerspace-bremen.de"
>>> as_token = "..."  # Taken from the bridges registration.yaml
>>> client = ClientAPI(puppet_user, base_url=base_url, token=as_token, as_user_id=puppet_user)

Sicherstellen, dass der Client funktioniert. Zum Beispiel, indem man die aktuellen Räume des Users abfragt:

>>> await client.get_joined_rooms()
['!room_id_1:hackerspace-bremen.de', '!room_id_2:hackerspace-bremen.de', ...]

Wenn diese richtig aussehen, kann für einen Raum der Power Level des Benutzers geändert werden. Um die Power Level in einem Raum zu ändern muss ein komplettes m.room.power_levels-Event an den Raum geschickt werden. Am einfachsten ist es, das aktuelle Event des Raums zu nehmen und zu bearbeiten.

>>> room_id = "!room_id_1:hackerspace-bremen.de"
>>> states = await client.get_state(room_id)
>>> len(states)
22

Das aktuelle m.room.power_levels-Event finden:

>>> power_state = [s for s in states if s.type.t == "m.room.power_levels"][0]

Das Event bearbeiten und den Power Level des Puppet-Benutzers auf 0 setzen:

>>> power_state.content.users[puppet_user] = 0

Anschließend das Event zurück zum Server senden:

>>> from mautrix.types import EventType, EventContent
>>> await client.send_state_event(room_id, EventType.ROOM_POWER_LEVELS, power_state.content)
'$...'

Wenn alles geklappt hat, hat der Puppet-Benutzer nun wieder den Power Level 0.

Blog Sprachen

2025-06-14T00:00:00Z

Ich habe mich dazu entschieden, die ganze Seite ab sofort zweisprachig in Deutsch und Englisch zu pflegen.

Optionsmenü mit Grafikeinstellungen in Godot

2025-06-09T00:00:00Z

Ich bearbeite gerade die 20 Games Challenge, in der man 20 kleine Spiele bauen soll, um verschiedene Aspekte der Spieleentwicklung zu lernen. Das Konzept, einen festen Scope zu haben und an kleinen Projekten zu entwickeln, hat mich überzeugt.

Mein Ansatz weicht aber in einigen Punkten ab, da ich mich gerne in Details verliere und mir gewisse Dinge ins Auge springen, die ich unbedingt umsetzen möchte. Ich bin gerade bei Spiel 3 und baue einen Frogger-Clon. Anders als in der Challenge vorgegeben baue ich allerdings ein 3D-Spiel und wollte ein Options-Menü bauen, in dem zur Laufzeit Qualitätseinstellungen ausgewählt werden können. Diese sollten über mehrere Spielestarts persistiert werden. Ein Beispiel für eine Einstellung ist MSAA 3D (3D Multisample Anti-Aliasing).

Die Auswahl einer Option im OptionButton hat dann ein Signal ausgelöst, das im Code des Dialogfensters etwa folgendermaßen behandelt wurde:

# [...]

func _ready() -> void:
    _setup_options()
    # [...]

func _setup_options() -> void:
    %msaa.clear()
    %msaa.add_item("Disabled", Viewport.MSAA_DISABLED)
    %msaa.add_item("2×", Viewport.MSAA_2X)
    %msaa.add_item("4×", Viewport.MSAA_4X)
    %msaa.add_item("8×", Viewport.MSAA_8X)
    %msaa.select(get_viewport().msaa_3d)

func _on_msaa_item_selected(index: int) -> void:
    get_viewport().msaa_3d = (index as MSAA)
    save_settings()

# [...]

Die Auswahl einer Option hatte allerdings keinen Effekt, ich konnte kein Anti-Aliasing im Spiel beobachten, die FPS blieben konstant und auch die Auslastung der Grafikkarte änderte sich nicht. Ich hatte sogar meinen Code mit dem „graphics_settings“ Projekt aus dem godot-demo-projects Repo verglichen und konnte keinen offensichtlichen Unterschied feststellen. Der Code in _on_msaa_option_button_item_selected ruft auch get_viewport().msaa_3d = ... auf. index entsprach dem korrekten Wert aus dem Viewport.MSAA-enum, den ich zum Testen sogar nach MSAA gecastet hatte^[1].

Nach einer Menge Debugging und dem Ausschluss aller anderen Optionen kam ich dann darauf: Mein Options-Dialog war, im Gegensatz zu dem Demo-Projekt, in einem eigenen Fenster. Die Klasse Window erbt von Viewport, was dazu geführt hat, dass mein Code nur die Einstellungen des Options-Fensters geändert hat. Mein Fix bestand darin, statt get_viewport() eine eigene Funktion zu bauen, die den Root-Viewport ermittelt und diese stattdessen zu verwenden:

func get_root_viewport() -> Viewport:
    return get_tree().get_root().get_viewport()

Was gar nicht nötig gewesen wäre. Man spart sich durch die Konstruktion den verbosen Code (if index == ...: get_viewport().msaa_3d = ... elif ...), man verliert aber durch die Verwendung des Index die Typinformationen und schleppt nur „implizit“ wichtige Informationen mit. Eine sauberere Lösung ist die Verwendung von Item-Metadata (set_item_metadata/get_item_metadata) an den Options-Einträgen, da dort Variants genutzt werden können. ↩

Neuer Blog

2025-06-08T00:00:00Z

Wie viele Entwickler kenne ich das Problem, die eigene Webseite zu pflegen, nur zu gut. Das letzte Update meiner alten Seite fand 2022 statt. Ich starte hiermit einen neuen Versuch. Damit verbunden ist der Vorsatz, generell mehr zu schreiben und mich auch bei Social Media (natürlich im Fediverse) stärker zu engagieren. Vorsätze haben einen durchwachsenen Ruf, bei mir lief es in der jüngeren Vergangenheit jedoch eher gut damit.

In diesem Blog möchte ich mich nicht nur auf technische Themen fokussieren, sondern auch über andere Dinge schreiben. Dinge die mich beschäftigen, über die ich nachdenke. Infrastruktur, die ich aufsetze. Projekte, an denen ich arbeite. Eventuell wird das für einige Dinge auch eine Art Devlog. Wer weiß.

Nachdem meine alte Seite mit Hugo gebaut war, bin ich jetzt wieder bei Zola. Als ich vor einigen Jahren noch mit Zola experimentiert hatte, war die Software noch nicht so weit. Mittlerweile bin ich aber überzeugt. Mein erster Blick auf Dinge, die in Rust entwickelt werden, ist in der Regel positiv.

Mir ist bewusst, dass ich mit der Umstellung Links brechen werden, da auch alte Inhalte nicht mit übernommen wurden. Ein sauberer Schnitt fühlt sich für mich gerade gut an. Da ich mir keinerlei Mühe gebe, irgendwelche Statistiken, Besucherzahlen, Seitenaufrufe o.Ä. zu tracken, weiß ich nicht, wie viele Aufrufe das betreffen wird – es ist mir auch egal.

1750 Hz Pfeife

2018-05-26T00:00:00Z

Für viele Amateurfunk-Relais ist ein Ton der Frequenz 1750 Hz zum Auftasten erforderlich. Als Spaßprojekt habe ich eine Pfeife entwickelt, die diesen Ton produziert:

Ich habe sie auf einem Anet A8 Drucker mit 0,1 mm Schichtdicke gedruckt und sie funktioniert tatsächlich. Je nach Druck werden Töne zwischen 1600 und 1850 Hz erzeugt, bevor die Pfeife überbläst und die Pfeife Obertöne produziert. Viele Relais ließen sich damit auftasten, wobei einige einen ziemlich stabilen Ton benötigten.

§ Download

STL Datei