My current focus is the comsat proof of concept simulation, but there are other older threads that remain below related broadly to passkey management.
Pitch: Revolutionize Communication with "Comsat"
Introduction:
Core Concept:
Key Features:
Value Proposition:
Market Potential:
Conclusion: Comsat grants users sovereign control over their time by controlling their virtual space. Whether users want to congregate in low Earth orbit or float alone in the expanse, Comsat offers the experience of deliberate, space-inspired messaging.
Architectural Overview:
Front-End UI (Spacecraft Interface):
HTML/CSS: Static HTML serves as the structure of the UI. CSS, potentially preprocessed with tools like SASS for advanced features, is used for styling to ensure a modern and responsive design.
HTMX: HTMX attributes added to HTML elements to handle dynamic content updates without writing JavaScript. Server interactions are managed with HTMX, such as sending and receiving messages, updating UI components, etc.
Back-End (Comsat Operations): Distributed Hash Table (DHT) for Node Discovery: Nodes (comsats) register themselves on the DHT. Comsats query the DHT to discover other nodes and retrieve the necessary connection information.
WebRTC for Peer-to-Peer Communication: Once nodes are discovered, WebRTC establishes a direct, peer-to-peer communication channel between comsats. WebRTC handles the transmission of data (e.g., chat messages, status updates) directly between comsats.
Communications between Front-End and Back-End: HTMX & Server Sent Events (SSE) or WebSockets: For real-time communication from server to client (comsat to spacecraft), use SSE (a unidirectional protocol where the server sends updates) or WebSockets (a bidirectional communication protocol). HTMX can interact with the server to send spacecraft commands and receive updates, which are then displayed to the user.
Architectural Flow:
Spacecraft 1 UI (Client) <--> Comsat 1 (Server/Node)
Comsat 1 <--> Comsat 2 (Peer-to-Peer via WebRTC)
Comsat 2 (Server/Node) <--> Spacecraft 2 UI (Client)
This architecture supports a decentralized system where each spacecraft-comsat pair operates independently. There's no central server managing the communications; each comsat finds its peers through the DHT and establishes a direct line of communication via WebRTC. HTMX on the front end allows for a responsive user experience with real-time updates from the comsat without relying on any JavaScript frameworks.
Local LLM for Enterprise
Slide 1: Title
Slide 2: Problem Title: "The Challenge of Data Security in AI"
Slide 3: Solution Title: "Our Solution: Local LLM Server"
Slide 4: Market Opportunity Title: "Market Potential and Target Audience"
Slide 5: Product Title: "Product Overview"
Slide 6: Business Model Title: "How We Make Money"
Slide 7: Competition Title: "Competitive Landscape"
Slide 8: Traction Title: "Our Progress So Far"
Slide 9: Team Title: "Meet Our Team" Bullets:
Slide 10: Ask Title: "What We Need"
The vision for the voidKey product is to have passwordless key management ready at hand for everyone. The branding refers to the solution's function; the user's keys will be stored within a void created by a Faraday cage that defaults closed and opens with a single motion.
Images
Use Cases
While both use cases below share the assumption that this object would be part of a more comprehensive authentication scheme, they differ fundamentally in the need that they are satisfying. Another area of reasearch is which of these two use cases to focus on. Is identity management sufficiently served by existing hardware security tokens, such as YubiKey, Thetis, Google Titan Security Key, etc.? Is there a demonstrable need in the crypto community for another option at a lower price point?
Identity Management
This would be relevant to a passwordless authentication scenario.
Cryptocurrency Cold Wallet
This would be relevant to a new class of cold wallet that sits between paper & pencil and electronic hardware wallets.
Framework
I have a tentative framework with which I believe it would be useful to analyze the existing solutions. The framework consists of two axes: complexity and connectivity. Each axis is a spectrum from simple to complex or from always offline (cold) to always online (hot).
Complexity: The simplest example is a pencil and paper that records a mnemonic word list. The most complex example is a hardware device such as those produced by Trezor.
Connectivity: The most offline examples are a pencil and paper or a metallic punch product. The most online is a hot wallet, such as a mobile app with an HD wallet.
Methodology
The approach that I'm taking is to ask relevant communities how they feel about their options and experiences to discover what pain points exist.
Questions
Prototype
I've built a few prototypes, the first of which was made from tape, cardboard, and an NFC laundry tag. The most recent iteration, v0.4, was 3D printed in PLA and continues to use an NFC laundry tag. There were issues witht that print, and I am currently working on v0.5 to mitigate some of those issues. One open issue is whether it's necessaryt to completely enclose the object in conductive film or whether small openings are acceptable. Initial testing is likely to yield an answer.
Benefits
This object could likely be produced at a low enough cost to manufacture and distrubute widely so that businesses could offer it at zero additional cost as part of a package.
What appeals to me about the promise inherent in blockchain technologies is that there is at least a hint of a possibility that we can avoid exploitation and alienation with tokenized ownership.
This reminds me of an approach we came up with when we were struggling with identity management in the context of self-custody. We circled the idea of storing identity-related information on chain like we did device information on the Stellar network so we could support persistent secure login. We never got around to implementing this, but my idea was to put the pointer to the information embedded in a Stellar transaction and put the actual information payload in IPFS. That could be PII, like a 3D point cloud of your face, other biometric information, documents, or (a lot less scary) your contacts. I hate this phrase, but you'd have "sovereign control" over what constitutes your identity and you could grant fractional access. I felt like that same idea could be applied to various social networks so that you can be both anonymous and secure in a zero trust way. There could be implicit trust in a refuge, but the cost would be hardcore KYC. I can't take credit for the germ of this idea (the bit about tokenizing identity information).