pinpon: A gateway for various cloud notification services

This is a package candidate release! Here you can preview how this package release will appear once published to the main package index (which can be accomplished via the 'maintain' link below). Please note that once a package has been published to the main package index it cannot be undone! Please consult the package uploading documentation for more information.

[maintain] [Publish]

pinpon is a gateway for various cloud notification services, such as the Amazon AWS SNS service.

Think of pinpon as a hub for dispatching notifications originating from multiple notification sources. Clients of the pinpon service create topics and send notifications via the REST-ish pinpon service, and the pinpon server takes care of the per-service details and communicating with the upstream cloud services.

Advantages of this approach, compared to programming directly to the individual notification services' interfaces, are:

Currently-supported notification services:


[Skip to Readme]

Properties

Versions 0.2.0.1, 0.2.0.2, 0.2.0.2
Change log changelog.md
Dependencies aeson (>=1.1 && <1.3), aeson-pretty (>=0.8 && <0.9), amazonka (>=1.4.5 && <1.6), amazonka-core (>=1.4.5 && <1.6), amazonka-sns (>=1.4.5 && <1.6), base (>=4 && <5), bytestring (>=0.10.8 && <0.11), containers (>=0.5.7 && <0.6), exceptions (>=0.8.3 && <0.9), hpio, http-client (>=0.5.7 && <0.6), http-client-tls (>=0.3.5 && <0.4), http-types (>=0.9.1 && <0.10), lens (>=4.15 && <4.16), lucid (>=2.9.9 && <3), mtl (>=2.2.1 && <2.3), network (>=2.6.3 && <2.7), optparse-applicative (>=0.13.2 && <0.15), optparse-text (>=0.1 && <0.2), pinpon, protolude (>=0.2 && <0.3), resourcet (>=1.1.9 && <1.2), servant (>=0.11 && <0.12), servant-client (>=0.11 && <0.12), servant-docs (>=0.11 && <0.12), servant-lucid (>=0.7.1 && <0.8), servant-server (>=0.11 && <0.12), servant-swagger (>=1.1.4 && <1.2), servant-swagger-ui (>=0.2.4 && <0.3), swagger2 (>=2.1.6 && <2.3), text (>=1.2.2 && <1.3), time (>=1.6 && <1.9), transformers (>=0.5.2 && <0.6), transformers-base (>=0.4.4 && <0.5), wai (>=3.2 && <3.3), warp (>=3.2 && <3.3) [details]
License BSD-3-Clause
Copyright Copyright (c) 2018, Quixoftic, LLC
Author Drew Hess <dhess-src@quixoftic.com>
Maintainer Drew Hess <dhess-src@quixoftic.com>
Category Network
Home page https://github.com/quixoftic/pinpon#readme
Bug tracker https://github.com/quixoftic/pinpon/issues
Source repo head: git clone https://github.com/quixoftic/pinpon
Uploaded by dhess at 2018-03-17T21:01:10Z

Modules

[Index]

Flags

Manual Flags

NameDescriptionDefault
pinpon-executable

Build pinpon program

Enabled
pinpon-gpio-executable

Build pinpon-gpio program

Enabled
pinpon-ring-executable

Build pinpon-ring program

Enabled
test-doctests

Build doctests

Enabled
test-hlint

Build hlint test

Disabled

Use -f <flag> to enable a flag, or -f -<flag> to disable that flag. More info

Downloads

Maintainer's Corner

Package maintainers

For package maintainers and hackage trustees


Readme for pinpon-0.2.0.2

[back to package description]

pinpon

pinpon is a silly little service that implements an Internet-enabled doorbell in Haskell, using Amazon Simple Notification Service to notify subscribers that the button has been pushed. Effectively, it's a simple REST service which, when POSTed to, will send a notification to an SNS topic. You can then build a client application which subscribes to that topic and notifies the user when the doorbell has been pressed. No such client application is included in the pinpon package, but an iOS app may be made available at some point in the future.

The package provides a pinpon-gpio executable, intended for use on Linux systems with GPIO functionality. When the specified GPIO pin is triggered (e.g., via a momentary switch such as this one), pinpon-gpio will POST a notification to the specified pinpon server.

Why not simply build the Amazon SNS functionality into the pinpon-gpio executable and eliminate the pinpon REST service? Chiefly because the host system running the pinpon-gpio executable may be particularly vulnerable to physical attacks (after all, it is presumably hooked up to a doorbell button that is exposed in a public space). I did not feel comfortable storing my Amazon AWS credentials on such a device, nor even allowing such a device to communicate directly with the public Internet. By proxying the AWS access via a more physically secure host running the pinpon server on my internal network, I can better protect my AWS credentials and limit network access on the GPIO device to just the pinpon service.