Machine learning has become more and more powerful, to the point where a bad actor can take a photo and a voice recording of someone you know, and forge a complete video recording. Bad actors can now digitally impersonate someone you love, and trick you into doing things like paying a ransom. To mitigate that risk, I have developed this simple solution where you can setup a unique time-based one-time passcode (TOTP) between any pair of persons.

Github: https://github.com/ksze/PeerAuth

Piet is a programming language in which programs look like abstract paintings. The language is named after Piet Mondrian, who pioneered the field of geometric abstract art. I would have liked to call the language Mondrian, but someone beat me to it with a rather mundane-looking scripting language.

I wrote the Piet specification a long time ago, and the language has taken on a bit of a life of its own, with a small community of coders writing Piet programs, interpreters, IDEs, and even compilers. I have not written any "authoritative" interpreter, and the different ones available sometimes interpret the specification slightly differently.

Piet uses a stack for storage of all data values. Data values exist only as integers, though they may be read in or printed as Unicode character values with appropriate commands. The stack is notionally infinitely deep, but implementations may elect to provide a finite maximum stack size. If a finite stack overflows, it should be treated as a runtime error, and handling this will be implementation dependent.

It's hard to find good information on APRS. A web search produces mostly outdated misinformation and little of value. This is the beginning of a collection of the essential documentation.

Club meetings and ham conventions are always looking for speakers. There was nothing about APRS during the 2024 Dayton forums. Suppose you wanted to give an APRS presentation at a club meeting or ham convention. But... It's a big job. You are not sure where to start and would like to use / adapt something already done rather than starting from nothing. Where can you find suitable presentations? I’ve tried searching and could not find much that was worthwhile. I’m throwing this out as a challenge to the APRS community. Please help to make a list of the best presentations that others could use.

There is some very good material out there, but how can the newcomer find it among all the clutter? This is a crowd-sourced list of the best resources for a beginner. I need YOUR help to find the best resources.

RACE (Resilient Anonymous Communications for Everyone) is a distributed system developed to provide resilient, secure, anonymous messaging. You can think of RACE in terms of a network two types of nodes: clients and servers. The clients are devices run by individual users who want to anonymously message one another; the servers are run by volunteer users or organizations that provide the infrastructure to enable anonymous client messaging. Uses special multi-party computation (MPC) algorithms to route messages without individual servers learning the metadata. The specific goals of the original RACE program were to enable up to 20% of the servers to be malicious and colluding without any client messaging metadata being leaked.

On 1976 at the HomeBrew Computer Club (HBCC), there was a lot of whining about Bill Gates charging $150 for his Basic interpreter. Dennis Allison responded by printing a "Build Your Own [tiny] Basic" article, so I asked if anybody would buy it if it cost only $5. There seemed to be some affirmation, so I wrote my interpreter. Others jumped on the same article, and I wasn't the first done, but I wanted to be paid for my efforts. As far as I know, nobody at HBCC bought it, but I sent a freebie to Byte magazine and they printed a 1-inch announcement. The next month my mailbox was full of orders, every one with $5. I didn't get rich off it, but it did pay a lot of my expenses at grad school.

This is an archive of as many versions of TinyBasic, the documentation, the user and experimenter kits as Tom Pittman could find.

RACE is an open source project aimed at developing technologies to provide metadata-anonymous, secure, and resilient messaging for users around the world. RACE provides anonymity by routing messages through an overlay network of volunteer servers using cryptographic algorithms that prevent a malicious subset of these servers from determining who is messaging whom. RACE uses specialized networking protocols to prevent connections between individual members of the network from being detected or blocked. RACE is built to run in a dockerized linux environment and on Android devices.

This document defines the FediE2EE-PKD (Fediverse End-to-End Encryption Public Key Directory), which consists of ActivityPub-enabled directory server software, a protocol for communicating with the directory server, and integration with a transparent, append-only data structure (e.g., based on Merkle trees).

This repository serves as a historical archive containing specifications for the fictional hardware of the game 0x10c. The game was to be a multiplayer sandbox game set in space, with a fully programmable CPU controlling a ship. The game was cancelled in 2013 to much dismay of fans. A number of fan projects appeared aiming at continuing development, but they also appear to be abandoned.

There are a large number of fan works on GitHub, mainly implementations of the DCPU-16 hardware or code to run on it. GitHub still has a list of DCPU-16 ASM trending repositories. These usually included links to the official specifications which were either hosted on Pastebin or 0x10c.com. The later has been been offline since February 2014 (weirdly the domain was renewed for another year in April 2014), so this is my attempt to archive them for future reference.

This is my fork of the repo for later reference.

Defines a standard, programming language agnostic interface description for REST APIs, which allows both humans and computers to discover and understand the capabilities of a service without requiring access to source code, additional documentation, or inspection of network traffic. When properly defined via OpenAPI, a consumer can understand and interact with the remote service with a minimal amount of implementation logic. Aims to remove guesswork in calling a service.

A framework for building cryptographic protocols so you don't have to do it from the ground up. Mutual and optional authentication. Multiple languages supported.