wildcard

Full-stack digital product consultant @ BoundCorp.net - Regenfrogs.xyz - goldmongers.xyz - Reno NV

This feels like it’s getting unnecessarily personal (Google and then get back to me), so will try to keep it focused on the issues.

1. What current problem does Hub implementation diversity solve?

2. Shuttle is open source. We built it with feedback from folks like Neynar and Airstack. DCs and channel creation will be decentralized after we stop iterating on the core surface area. We don’t want to have many breaking changes for protocol primitives. 

3. Long casts were a backward compatible change. If it was breaking we would have moved slower. We also reach out to the developers in the ecosystem that regularly attend the open dev calls, have clients with a large number of active signers and anyone who reaches out to us.

4…

re 2. 

Shuttle is open source yes, but we still need to implement an app using it to replicate all the data

Since the schema is pretty much standard (old replicator) and the team already has an implementation (for WC), its not clear why the app implementation is not open sourced

Working on open-sourcing our implementation to replicate standard schema

building /wildcardclub

(prev. @alliance, @ycombinator, @0xppl)

The app can be versioned, each change is opt in explicitly

Sounds messy. 

fwiw, we've asked other client developers and open sourcing tends to be much lower on the priority stack relative to growth, DCs, frames, channels, etc.

I mean you seem more interested in DCs than open source Warpcast?

Yes absolutely, this is much lower priority. 

We’ll open source our bit for reference.. this was just about preventing repetitive work.

DCs >> channels >> everything else

Right, so then why are we having a conversation about something so far down the priority stack.

I think open source Warpcast would be good! But it's not a top priority and developers in the ecosystem (like yourself) never ask it to be.

Feels like it's a strawman argument that set of users on the network use to criticize. We're fine ignoring them, since we're focused on the developers that have skin in the game.

We are willing to work with breaking changes over not having interoperability with DCs

Its reported as the single biggest reason why people have to “necessarily go back” to Warpcast, and have a split client experience.

Would be great if we can have interoperability.

It can be: getting a session token from WC by making an authenticated request. And being able to read the APIs that Warp uses. Nothing fancier.
We already have the write APIs.

@dwr.eth

Would love to know your thoughts on this Dan

If we're going to do it, we'll support it properly.

Shipping APIs that could change / break creates angry users.

Would love to know your thoughts on this Dan

https://warpcast.com/defikaran.eth/0x73f76727

From Wildcard’s perspective,
Open source Warpcast doesnt add value as much as open DCs, channels.

My open source 2 cents were re shuttle app, which is an independent, very small thing.

Open source complete client code is a pain, and I cannot be the one to comment on it as I haven’t made Wildcard open source and am aware of the challenges it poses.