RFE: remove pusher.com dependency

[danielefranceschi]

Similarly to #33: in order to deploy a full private solution, a private server could be easily deployed via docker, given an almost-standardish nodejs Dockerfile.

Nevertheless, pusher.com is an hosted solution, which could be not desirable for organizations with an high confidentiality policy. Their on-premise solution is presumed to be expensive, but this is not what I'm discussing.

Is there any chance of replacing pusher.com with an OSS equivalent solution?

[gillesdemey]

If you want to go for a complete private deployment you'd also have to replace Twilio and host your own STUN server.

[nathansobo]

I'd definitely be open to moving away from Pusher and handling web sockets directly in teletype-server itself, with connections between instances brokered by something like Redis streams. That would make it easy to continue to run the server on Heroku and minimize our ops burden. We went with Pusher just because it was super super easy and we wanted to focus efforts elsewhere. We're in the same situation now.

If someone wants to contribute a solution along these lines or has an alternate proposal that's easy to host on Heroku with minimal ops burden, I'm open to hearing a proposal. We'd need someone from the community to spearhead it, but I'm on board to shepherd it forward.

Keep in mind that we have to run the default instance of this server, so any proposal would need to take into account a practical transition plan that could proceed incrementally. Could we move 5% of connections to our own web sockets implementation, make sure we're still good, then 10%, etc.

[dAnjou]

@gillesdemey Would you also need a STUN server if you are in the same physical network or VPN?

[ProfileSeeker]

Our network policy makes it impossible to talk to pusher and alternatives. Any way to make it run 100% locally?

[jasonrudolph]

Any way to make it run 100% locally?

@andros705: I think you'd need an on-premise version of Pusher or something equivalent to it, and you'd also need an on-premise replacement for the Twilio bits (as mentioned in #35 (comment)). We probably don't have the resources to provide much support for people pursuing this approach, but if you make any progress in this area, I'd love to hear about it.

[rriemann]

I would like to suggest the public sector to use markdown in atom with teletype for collaborative editing of legal texts and versioning with git thanks to the recent GUI integrations in atom. At the moment, sending *.doc files per mail is common practice. 😭

You can imagine that dependency on third parties (outside of the own jurisdiction) are kind of a deal breaker.

[tomdantuit]

@nathansobo, @jasonrudolph

If someone wants to contribute a solution along these lines or has an alternate proposal that's easy to host on Heroku with minimal ops burden, I'm open to hearing a proposal.

Would you be open to replacing the Pusher/Twilio dependencies with open source alternatives that support hosting on-premise? Specifically, we're interested in replacing Pusher with Deepstream and replacing Twilio with Coturn.

Coturn supports RFC5245 & RFC5389, so our intent would be to support both Coturn and Twilio with the determination of which to use being based on the presence of the environment variables.

We'd take a similar approach concerning the Pusher dependency, implementing a DeepStreamPubSubGateway for the server/client and determining which to utilize based on the presence of environment variables.

Keep in mind that we have to run the default instance of this server

The option to still utilize Pusher and Twilio would still exist, so there shouldn't be any changes required in terms of maintaining the default instance. We just want to take the approach of adding additional options for those that need to run a completely on-premise implementation.

This is a potential project my team and I are looking to pick up over a 10 week PI this summer and wanted to run the proposed solution by everyone in this thread before we go too far down the path of implementing.

[jasonrudolph]

Keep in mind that we have to run the default instance of this server

The option to still utilize Pusher and Twilio would still exist, so there shouldn't be any changes required in terms of maintaining the default instance.

@tomd8451 Thanks for getting in touch. I'm 👍 on a solution that allows people to opt in to using an alternative to Pusher and an alternative to Twilio.

I'd love to see an implementation where:

• A separate npm module implements the DeepstreamPubSubGateway. (The repository might be named something like teletype-server-deepstream and it could live under the @8451 organization account, your personal account, or wherever else feels appropriate.)
• By default, atom/teletype-server continues to use PusherPubSubGateway.
• Given an environment variable or some other configuration, atom/teletype-server can determine that it should use an alternative pub-sub gateway implementation.

By having the Deepstream implementation live in a separate repository, you'd be able to more quickly and independently iterate on it without needing to wait for review from the folks maintaining atom/teletype-server. Also, this would presumably open the door for interested parties to develop other pluggable pub-sub gateway implementations for teletype-server.

Ideally you could use a similar approach for having Twilio as a default provider and Coturn as an alternative provider.

What do you think?

[rriemann]

Any news? I see there are non-merged pull requests.

[adamlwgriffiths]

I've merged the master onto the teletype-server branch here: nonameentername#1
Be good to get the ball rolling on this.
Help testing would be appreciated.

[chongchai]

@adamlwgriffiths Your PR replacing pusher dependency is a big step to on-prem hosting setup.
I have a question:
To build a teletype-server in a local network and use teletype in this network, is there anything more need to be done?
Currently I still need to access github.com for oauth token and api.teletype.atom.io for user infomation.

[adamlwgriffiths]

Credit goes to @nonameentername, I just resolved the merge conflicts.

It seems that is what is needed currently.
I would love to have those removed as I see no need for small teams on VPNs or private networks to use Github for user authentication. I'm not in a position to be able to make those changes though.

I'm not currently setup to get OAuth working, so I haven't been able to actually test the changes beyond running the server and verifying it didn't crash. So some help with that would be great.