ability to consume events from 3rd party app

[tomholub]

I would utilize some way to consume events from a third party app. I'm specifically interested in:

• a new key (added through gossip or uploaded directly)
• key updated

The simplest way to do this would be, subject to configuration, to have an events folder and dump the keys there one by one as files (eg events/0xXXXXXXXXXXXXXXXX.asc) as these events happen.

I may take some time to familiarize myself with the codebase. Would a PR for this be accepted?

A more advanced approach would be to set a callback url in the config, but then we have to worry about timeouts, retries, etc and it may get unnecessarily complicated.

[cmars]

I'm not sure if there's much general demand for this kind of feature to land it in this project and support it (convince me if I'm wrong though). Sounds like this could be implemented as HTTP middleware. I'd accept a contribution like a new Server constructor that you pass additional middleware to. Then you could build your own custom server reusing existing components.

[tomholub]

Sounds perfect, thanks!

On Tue, Jul 17, 2018, 00:22 Casey Marshall notifications@github.com wrote:

I'm not sure if there's much general demand for this kind of feature to land it in this project and support it (convince me if I'm wrong though). Sounds like this could be implemented as HTTP middleware. I'd accept a contribution like a new Server constructor that you pass additional middleware to. Then you could build your own custom server reusing existing components.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/hockeypuck/server/issues/21#issuecomment-405304095, or mute the thread https://github.com/notifications/unsubscribe-auth/AGA8kQEj0tVaLw_h7rcB4UFvmhu4W-voks5uHL3FgaJpZM4VQb9N .

[tomholub]

To satisfy the AGPL license, we will open source all of our modifications to Hockeypuck plus whatever middleware we design, but not external services that talk to Hockeypuck over an API - is that correct?

[cmars]

From the AGPL FAQ:

Q: How does this license treat commercial enterprise use over intranets and internal networks? A: Simply, if run internally to a commercial company, then the company isn't required to release source code back to the world. The license requires that if a user downloads the source they have the right to make improvements and not release these modifications. GNU GPL software in general addresses this issue the same way. If an employee has access to the source and has the right to make improvements, the commercial entity could probably view this work as work for hire and owned by the company and not have to be released outside.

So I think it sounds fine, as long as you're not running these external services on public networks.

[tomholub]

The setup would be:

other sks servers <> hockeypuck (open source) <> internal service (closed source) <> service with a public api (closed source)

Any modifications to hockeypuck would be open sourced, but not the other services. Is this acceptable? It feels it should be, just wanted to confirm.

[cmars]

Yes, this is OK.