pinpon: A gateway for various cloud notification services

[ bsd3, library, network ] [ Propose Tags ]

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:

  • A common API for all supported notification services.

  • The secret credentials required to communicate with each cloud notification service can be kept in a central location (namely, the pinpon server), rather than being distributed to each notification source host, therefore reducing the attack surface.

  • Hosts which send notifications via the pinpon gateway can be firewalled from the public Internet. This is especially useful in IoT applications.

Currently-supported notification services:

  • Amazon AWS SNS

[Skip to Readme]


Manual Flags


Build pinpon program


Build pinpon-gpio program


Build pinpon-ring program


Build doctests


Build hlint test


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


Maintainer's Corner

Package maintainers

For package maintainers and hackage trustees


Versions [RSS],
Change log
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 <>
Maintainer Drew Hess <>
Category Network
Home page
Bug tracker
Source repo head: git clone
Uploaded by dhess at 2018-03-17T21:02:10Z
Executables pinpon-ring, pinpon-gpio, pinpon
Downloads 1144 total (7 in the last 30 days)
Rating (no votes yet) [estimated by Bayesian average]
Your Rating
  • λ
  • λ
  • λ
Status Docs uploaded by user
Build status unknown [no reports yet]

Readme for pinpon-

[back to package description]


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.