Aggressive Interoperability

[noahlevenson]

Right now, everyone in this space is clamoring for The One Interoperable System to Rule Them All. If you're really in this field, you know that the current problems are all about unifying proxies from different projects under a single technology, and avoiding duplication of work -- both in building tech and building userbases.

As we've always suspected, our big opportunity here is in interoperability.

The problem: in trying to rush BU to market for use with Lantern, we've incrementally jeopardized our interoperability.

We need to pause, survey our current state of interoperability, back out our bad decisions, and start leading -- in our comms and the presentation of the project -- with interoperability.

We need to make a list of all the projects we'd like BU to interoperate with -- Tor, Signal, and what else?

Maybe we can organize hackathons focused on making BU work as a transport for these potential partners, and then use the solutions to identify places where we're not providing the right interfaces and such?

[myleshorton]

I think the primary missing piece for interoperability is a client-side SDK that folks can integrate that would use this on the backend. Without that, I don't think it's really possible to do.

[myleshorton]

So true interoperability is a big lift. I think the main approach to interoperability now is to make it such that there's no Lantern-specific anything in the code base along with the ability to make the widget itself easily whitelabeled.

[noahlevenson]

@myleshorton What do you mean? Isn't the clientcore module what you're talking about?

[myleshorton]

No ideally that would be packaged like a true SDK on mobile a la any other mobile SDK. See, for example, Stripe integration on Android:

https://github.com/stripe/stripe-android#configuration

Folks certainly could interact with it directly only the code level, but usually it would have a little more packaging.

[myleshorton]

That's the direction we're going with Mesa regardless, though, so we could either provide broflake separately or as a part of the Lantern Mesa SDK that's not yet a thing.

[noahlevenson]

Oh -- I guess from my POV, that's often where a mature product ends up -- with a polished SDK -- but to get in early and capture the market, you just convince some implementers to work with your library, and you provide a lot of hand holding tech support.

[myleshorton]

That's fine too. I think then this is likely mostly a matter of writing super simple documentation for how people could actually run this. They'd also, though, have to be able to run their own freddie and egress servers.

[noahlevenson]

I think part of the provocation should be figuring out how to create a scalable global mainline of Freddie and egress... this is also the focus of the Snowflake team currently