Jason Bowman sini

Generating Authy passwords on other authenticators

The code below has been updated to remove a dependency on jquery and format urls for Authy 7 digit keys and 6 digit keys.

There is an increasing count of applications which use Authy for two-factor authentication. However many users who aren't using Authy, have their own authenticator setup up already and do not wish to use two applications for generating passwords.

Since I use 1Password for all of my password storing/generating needs, I was looking for a solution to use Authy passwords on that. I couldn't find any completely working solutions, however I stumbled upon a gist by Brian Hartvigsen. His post had a neat code with it to generate QR codes (beware, through Google) for you to use on your favorite authenticator.

His method is to extract the secret keys using Authy's Google Chrome app via Developer Tools. If this was not possible, I guess people would be rever

Keybase proof

I hereby claim:

I am sini on github.
I am sinistar (https://keybase.io/sinistar) on keybase.
I have a public key ASBZ7hwVjAJ-BfZTJio-xVp_5M_d_agzjmvBvisjnM9Mzwo

To claim this, I am signing this object:

Traits, Structural Nesting, and Schema-Driven Classes

Date: 2026-04-25 Status: Draft Authors: Vic, Sini (with agent assist) Supersedes: 2026-04-16 Capabilities spec (draft)

Problem

Den aspects currently treat all non-structural keys as class modules. There is no distinction between:

Direct-Ref Policy Aspects + Entity Simplification

Date: 2026-04-26 Branch: feat/traits Status: Draft Prerequisite: Stages elimination (complete)

Problem

The stages elimination introduced den.entityIncludes as a per-kind aspect list with string-keyed lookup. This creates several workarounds:

Unified Policy Effects Design

Status: Approved

Core Insight

Policies are effect-producing functions. Their function signature determines when they activate (context matching), and they return typed policy effects that the pipeline processes. Evaluation is commutative — order between policies doesn't matter; dependencies are implicit in signatures.

Function signatures are the universal API. Aspects declare what context they need ({ host, user, secrets }:), the pipeline matches arg names to handlers — whether the value comes from an entity binding, trait collection, or policy injection.

Policy Pipeline Simplification

Status: Draft

Prerequisites

Unified policy effects (2026-04-27) implemented
Mutual-provider replaced with policyFns
All test fixture policies converted to __functor (in progress)

Provides Backwards-Compatibility Shims

Date: 2026-04-28 Branch: feat/fx-pipeline Status: Draft Prerequisite for: Provides removal (2026-04-27-provides-removal-post-unified-effects.md)

Problem

Users migrating from main to the merged feat/fx-pipeline branch hit hard errors and silent behavioral breakage:

Policy Context Enrichment & Post-Pipeline Class Wrapping

Date: 2026-04-28 Branch: feat/fx-pipeline Status: Design approved

Problem

Two related gaps prevent policy-injected context from reaching class modules:

	{ config, lib, pkgs, ... }:

	with lib;

	let
	cfg = config.services.ceph-benaco;

	inherit (pkgs.callPackage ../helpers.nix {}) ensureUnitExists;
	in

	{
	self,
	inputs,
	...
	}:
	{
	text.readme.parts.colmena =
	# markdown
	''
	## Remote deployment via Colmena