Most electronic setups make the human follow the machine clock. I’m interested in the opposite: letting the drummer become the clock/conductor, so the modular system follows the drummer’s timing instead of forcing everything onto a fixed grid.

For modular users, I’m curious how you’d want something like this to work in practice. Would it be most useful as MIDI clock, CV clock, trigger/gate extraction, tempo following, clock division/multiplication, or something more performance-oriented?

The goal would be to keep the feel human while still giving the modular system enough structure to stay locked in musically.

Hey everyone, I’m looking for open-source apps that want help improving auth or security.

I’m working with Tide, which is decentralized auth.

Would love to try it on real projects where login, account recovery, admin access, or permissions have known vulnerabilities but are a pain to upgrade.

Not selling anything, just looking to contribute and test it with real apps.

Drop your repo if you’re interested.

Hey everyone, I’m looking for open-source apps that want help improving auth or security.

I’m working with Tide, which is decentralized auth.

Would love to try it on real projects where login, account recovery, admin access, or permissions have known vulnerabilities but are a pain to upgrade.

Not selling anything, just looking to contribute and test it with real apps.

Drop your repo if you’re interested.

Hey!! I vibe coded KeyleSSH, a keyless access layer for infra powered by TideCloak.

The simple version is: I wanted a way for teams to access servers, private networks and remote desktops without dealing with SSH keys, passwords, VPN creds, shared admin accounts, or random standing secrets everywhere.

Right now KeyleSSH is targeting:

• SSH access
• PAM / Linux login
• QUIC based VPN access
• browser based RDP with JWT access
• users, roles and access managed through TideCloak

Why TideCloak is the moat

The reason I keep talking about TideCloak is because it is the real differentiator of KeyleSSH.

Without TideCloak, KeyleSSH could sound like another access tool that supports a few protocols. That is useful, but the protocols are not really the moat. Someone can always build another SSH wrapper, another VPN flow, or another browser RDP gateway.

The moat is the control plane underneath it.

TideCloak gives KeyleSSH identity, access management, governance, users, roles, sessions and access claims from the start. Instead of building a protocol tool first and then bolting auth on later, KeyleSSH is built around TideCloak-managed identity from day one.

That changes the architecture. KeyleSSH does not need to become a credential manager. It does not need to store reusable keys, passwords, VPN secrets or shared admin credentials just to let people connect. TideCloak handles who the user is, what role they have, and what they are allowed to access.

Then KeyleSSH turns that TideCloak-backed authority into access across the protocols people already use: servers through SSH, Linux login through PAM, private services over QUIC VPN, and remote desktops through browser RDP.

That is the moat for me: KeyleSSH is not just keyless SSH. It is TideCloak-powered infrastructure access across multiple protocols.

How I vibe coded it

My workflow was design first, then design with AI, then implementation loops.

I did not start by asking AI to build the whole thing. I first mapped out the product experience I wanted: user signs in, sees what they are allowed to access, clicks connect, and does not have to think about SSH keys, VPN configs, passwords, or RDP creds.

Once the product shape was clear, I gave AI the TideCloak SDK clone repo to digest. That was a big part of the process. Instead of asking vague questions like “how do I add auth,” I could ask specific implementation questions against the actual SDK structure:

• Where should the TideCloak client sit in the app?
• Which SDK flows should handle login and session state?
• How should I pull users, roles and access claims?
• Where should short-lived JWT authority be created or verified?
• How should DPoP-style proof of possession fit into the request flow?
• What should KeyleSSH own versus what should stay inside TideCloak?

After that, I started iterating on implementation. The loop was basically: ask how to implement a piece, generate a first pass, compare it against the SDK patterns, test it, hit an edge case, then refine.

The rough flow became:

1. User signs in through TideCloak
2. TideCloak manages users, roles and access claims
3. KeyleSSH receives short-lived JWT-based access authority
4. DPoP-style proof of possession binds that session to the user’s device
5. Tide Secured cryptography backs the access authority behind the scenes
6. KeyleSSH translates that authority into SSH, PAM, QUIC VPN and browser RDP access

From the user side, I want it to feel boring in a good way. Under the hood, there are no long-lived creds being handed around. No SSH keys to manage, no standing passwords to share, no VPN secrets sitting in config files.

Tools / stack

Main pieces I used:

• TideCloak for IAM, IGA, users, roles, sessions and access claims
• Tide Secured cryptography for fragmented access authority
• JWTs for short-lived access
• DPoP-style proof of possession for device-bound sessions
• PAM for Linux login
• QUIC for VPN-style private service access
• browser RDP for remote desktop access through the web
• AI coding tools for architecture exploration, repo digestion, implementation planning, scaffolding, debugging, refactoring, naming and copy

Build notes / things I learnt

The biggest thing I realised is that “keyless SSH” is way too small of a description.

At first I was thinking about the app mostly through the SSH lens, but that framing broke pretty quickly. The same identity-backed access model could be used for machine login, private network access and remote desktop sessions too.

That changed the whole product shape. Instead of treating each protocol as its own separate access problem, KeyleSSH became one TideCloak-backed access layer that can translate the same user, role and session context into different infra entry points.

Another thing I learnt is that vibe coding is really good for moving across layers quickly, but you need a strong architectural constraint or it gets messy fast. For me, the constraint was simple: KeyleSSH should not become a credential manager. TideCloak owns identity and access control. KeyleSSH translates that into protocol access.

Design first helped a lot here. If I had started straight from code generation, I probably would have ended up with a pile of features. Starting from the user flow made it easier to decide what belonged in TideCloak, what belonged in KeyleSSH, and what should not exist at all.

Giving AI the TideCloak SDK clone repo also changed the quality of the answers. It meant the implementation advice was grounded in the actual repo patterns instead of generic auth advice. That made the loop way more useful: understand the SDK, ask how to implement one part, test it, then tighten it.

What I’m working on now

I’m getting the Shipboost launch page ready and trying to make the messaging not sound like generic zero trust slop.

The claim I’m trying to explain is:

KeyleSSH lets teams access infra through SSH, PAM, QUIC VPN and browser RDP without managing keys, passwords or standing secrets, because TideCloak is the identity and access control plane and Tide Secured cryptography backs the access authority.

Would love feedback on:

1. Does the TideCloak angle make sense as the main differentiator?
2. Would you call this keyless infra access, secretless access, or something else?
3. Is the build explanation clear enough or too hand wavy?

No keys. No passwords. No standing secrets. Just TideCloak-powered, device-bound access across the protocols infra teams already use.