Easy Amiibo Emulation - https://bit.ly/2z0m09k
(^ that's a short-link to this page, so you can open it in Linux)
Some users are discussing this guide in #hacking on the JoyConDroid Discord: https://discord.gg/SQNEx9v.
DO NOT ask for, or share links to, Amiibo bins in the comments! They will be removed. Thank you for understanding.
Add kiosk.js file with the content below to your www folder in config.
Like any other custom script, use ui-lovelace.yaml resources section to reference the kiosk.js file.
Make sure you add kiosk somewhere in your URL. You can use it in the id of your view or in the query string.
Written for fairly adept technical users, preferably of Debian GNU/Linux, not for absolute beginners.
|
You'll probably be working with a single smartcard, so you'll want only one primary key ( |
| diff --git a/src/client.rs b/src/client.rs | |
| index 3fb7f56..9740132 100644 | |
| --- a/src/client.rs | |
| +++ b/src/client.rs | |
| @@ -433,7 +433,7 @@ impl Client { | |
| // // private | |
| /// Constructs the full URL for an API call. | |
| - fn build_url(&self, member: &Member, path: &str) -> String { | |
| + fn build_url(member: &Member, path: &str) -> String { |
These commands generate and use private keys in unencrypted binary (not Base64 “PEM”) PKCS#8 format. The PKCS#8 format is used here because it is the most interoperable format when dealing with software that isn't based on OpenSSL.
OpenSSL has a variety of commands that can be used to operate on private
key files, some of which are specific to RSA (e.g. openssl rsa and
openssl genrsa) or which have other limitations. Here we always use
| module Modules.Auth.Login.Msg exposing (..) | |
| import Http exposing (Error) | |
| import Types exposing (User) | |
| type LoginMsg | |
| = LoginUpdateEmail String | |
| | LoginUpdatePassword String |
| #!/bin/bash | |
| # --------------------------------------------------------- | |
| # Customizable Settings | |
| # --------------------------------------------------------- | |
| MOUNT_POINT="${CASE_SAFE_MOUNT_POINT:-${HOME}/casesafe}" | |
| VOLUME_PATH="${CASE_SAFE_VOLUME_PATH:-${HOME}/.casesafe.dmg.sparseimage}" | |
| VOLUME_NAME="${CASE_SAFE_VOLUME_NAME:-casesafe}" | |
| VOLUME_SIZE="${CASE_SAFE_VOLUME_SIZE:-60g}" |
Requirements for room event storage:
- Lossless storage of the event JSON as the signatures need to remain valid (this is most easily done by simply storing the serialized JSON in a binary column)
- Able to work out the state of the room at any given event.
- Able to traverse the rooms event in topological order (for federation).
- Able to fetch new events for users (including events in rooms that the user is in and membership changes in any room, e.g. invites)
- Able to fetch the most recent N events in each room that the user is in (for initial syncs). In the future initial syncs will most likely be paginated and so the server will need to be able to fetch the most recent recent N events in the most recent M rooms.
- Able to fetch events older than a given point in a room (for back pagination).
| CREATE TABLE schema_version( | |
| Lock CHAR(1) NOT NULL DEFAULT 'X' UNIQUE, -- Makes sure this table only has one row. | |
| version INTEGER NOT NULL, | |
| upgraded BOOL NOT NULL, -- Whether we reached this version from an upgrade or an initial schema. | |
| CHECK (Lock='X') | |
| ); | |
| CREATE TABLE applied_schema_deltas( | |
| version INTEGER NOT NULL, | |
| file TEXT NOT NULL, | |
| UNIQUE(version, file) |