GooseClip originated in a frustration at the lack of interoperability of our modern devices. We have smartphones in our pockets, super computers on our desks, yet to send something from one to the other is surprisingly difficult, especially if that file is large or sensitive. The name GooseClip originates from GOOS (pronounced goose - a build command for creating multi platform binaries using the programming language Go) and clip, short for clipboard. On the journey to build a clipboard synchronization tool I discovered the world of peer-to-peer and understood that while it is undeniably a technology of the future, it's barrier to adoption by regular businesses is enormous. The GooseClip that exists today, which my project will be referring to, is an attempt to make integrating peer-to-peer into any product as easy as building a regular server-oriented product.
What it does
GooseClip obscures the complexity of peer-to-peer networking by presenting a simple 2-route API, /attach and /connect. Any business can integrate GooseClip into their existing or new products simply by bundling the library or daemon and invoking the connect route e.g. /firstname.lastname@example.org.
To demonstrate GooseClip I've built several mini-products on top of the platform to highlight the ease with which p2p can be added, and various different possible applications of fast, secure networking.
The simplest form of a GooseClip p2p connection. The direct 1 to 1 connection which could be compared to a regular TCP socket (except with e2e encryption, peer discovery and authorization).
Send and receive large files direct from the CLI.
goose clip sync
Synchronize your clipboards across devices!
GooseClip mobile library
Adds GooseClip functionality to an app.
Authorization / Authentication / Peer discovery
A huge part of making GooseClip viable was allowing organizations to control their own security / user identities and discovering peers. GooseClip does not store any user's personally identifiable information.
How I built it
The GooseClip daemon is built in Go, and cross compiled to Linux, Mac, Windows, Android or iOS.
GooseCLI which is shown in the project video is also built in Go and wraps the goose daemon, adding custom application logic for multiplexing the p2p connection to create the various apps.
The GooseClip app seen in the demonstration video is built using Flutter, which invokes Kotlin which in-turn interacts with the GoMobile compiled GooseClip library.
I've created a Go implementation of PKCE authentication for the command line, and a subtly different version for IDPs such as Github and Google.
GooseClip's backend handles all the necessary p2p signalling required to establish a connection. It's built in Google Cloud Platform and is using a combination of Serverless technologies such as Cloud Run, Cloud Functions, Datastore, Cloud Build, Container Registry, Cloud DNS and Cloud Storage and regular servers using Compute Engine. The APIs are written with Go.
AuthZ / AuthN
Okta is configured with two Identity Providers, GitHub and Google, as well as Okta itself acting as a self-registering user store. A few customizations are required to get GooseClip and Okta working together.
- A user must create a @Usertag during registration, this should be added to the IDToken.
- Groups starting with # should be added to the IDToken.
- Inline hook should be created to ensure @Usertag is valid.
- Users should be automatically added to #me on register if @me target functionality is desired. > Of course any additional security factors can be added or removed, such as MFA or passwordless sign in.
GooseClip and Okta work together by first creating a GooseClip organization using your Okta domain and ClientID, which is then used along with the GooseClip organization ID and ID tokens to authenticate and verify user requests.
Challenges I ran into
Just about every step of the hackathon was a challenge in one way or another.
Having never used Okta before I needed to learn the strengths and quirks of the new Identity Platform to understand how I could utilize it to delegate all user information for authorization and authentication. A core prerequisite for me to begin GooseClip was to never store users' PII. Organizations using GooseClip maintain and secure their own userstore. I tried and failed to implement passwordless login, inline hooks for custom fields for IDPs (though successful for Okta created users).
Cross compiling Go to mobile was amazing but also came with it's own quirks. Working in the sandboxed app environment also puts a spanner in the works. GooseClip historically uses the filesystem regularly to buffer data as it comes in to prevent out-of-memory exceptions on large files. On mobile the use of the filesystem in such a way is not encouraged so alternative solutions were required. Unfortunately I ran out of time to handle files larger than 50MB from the Android app (The irony is not lost on me).
GooseClip is something used to build other things, so in order to demonstrate it effectively, I had to build not-just the platform itself, but the products which with it could be used. Some of the outcomes are satisfactory while others will need a bit of TLC before they could be used as products in their own right.
Accomplishments that we're proud of
I am very proud of what has been created. The GooseClip platform itself works almost without flaw during my latest testing, on even troublesome NAT's or devices such as mobile. I really believe that completely unforeseen products and industries could arise out of making P2P technologies accessible. I'm especially excited to see how the flourishing world of crypto smart contracts / NFTs and GooseClip distribution could interact.
What we learned
P2P is HARD and 3 minutes is not a lot of time to explain something.
What's next for GooseClip
I would like to get GooseClip ready for an Alpha launch and get it in the hands of some developers. From a feature perspective, I plan on implementing audio and video channels so that people create streaming products using GooseClip.