{"id":20984560,"url":"https://github.com/kaiyou/acm","last_synced_at":"2025-10-12T23:02:20.019Z","repository":{"id":149065712,"uuid":"99421262","full_name":"kaiyou/ACM","owner":"kaiyou","description":"Agnostic/acentric cloud messaging - free alternative to GCM/FCM","archived":false,"fork":false,"pushed_at":"2018-06-17T08:56:31.000Z","size":10,"stargazers_count":2,"open_issues_count":0,"forks_count":0,"subscribers_count":2,"default_branch":"master","last_synced_at":"2025-01-20T07:13:58.695Z","etag":null,"topics":["broker","notifications","protocol","security"],"latest_commit_sha":null,"homepage":null,"language":"Python","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/kaiyou.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2017-08-05T12:24:06.000Z","updated_at":"2018-06-17T08:56:32.000Z","dependencies_parsed_at":null,"dependency_job_id":"92f92cb0-40ff-45c6-bf74-81ebec801579","html_url":"https://github.com/kaiyou/ACM","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/kaiyou%2FACM","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/kaiyou%2FACM/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/kaiyou%2FACM/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/kaiyou%2FACM/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/kaiyou","download_url":"https://codeload.github.com/kaiyou/ACM/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":243392292,"owners_count":20283560,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["broker","notifications","protocol","security"],"created_at":"2024-11-19T05:53:53.384Z","updated_at":"2025-10-12T23:02:20.009Z","avatar_url":"https://github.com/kaiyou.png","language":"Python","funding_links":[],"categories":[],"sub_categories":[],"readme":"Agnostic/Acentric Cloud Messaging\n=================================\n\nThis project aims at providing the simplest possible mean to notify mobile\ndevices that an interactive application should display a notification and\nload the related contents from its server. It is primarily targeting\nAndroid devices for now.\n\nThe main goals are:\n - lower the battery usage on mobile devices that run messaging apps\n - remain free of Google Play Services\n - provide very simple, very agnostic APIs\n - provide protection from a malicious notification broker\n - run properly in constrained environments\n - be extensible to as many technologies as possible in the future\n\nProtocol\n========\n\nACM uses a specifically designed protocol described in\n[PROTOCOL.md](PROTOCOL.md). The protocol is available both over a\nsocket-based interface and a REST API.\n\nACM is acentric, meaning a device can register on any ACM server, simply\nby configuring the ACM endpoint. \n\nGeneral scheme\n--------------\n\nBoth the device (or individual applications in case the package is not\ninstalled system-wide) and application server MUST be able to register\non the same broker.\n\nSubscribing uses the following scheme.\n\n1. The client notification package connects to a broker (in socket mode)\n2. The app registers a new notification target, specifying the resulting\n   callback and topic type\n3. The system package generates a channel identifier and stores the relation\n   between the callback and channel\n4. The system package generates an encryption key for the notification\n5. The system package subscribes to the channel\n6. The application communicates the broker, channel and encryption key to the\n   application server\n\nNotifying uses the following scheme.\n\n1. The application server generates a notification, potentially\n   attached with a structured payload\n2. The current timestamp and event unique identifier are attached\n   to the payload, which is encoded\n3. The notification content is encrypted using an authenticated\n   encryption scheme and the key initially passed by the client\n4. The notification is published on the broker and channel specified by the\n   client\n5. The client notification package decodes and decrypts the notification\n6. The client notification package checks the timestamp is recent and stores\n   the unique id in a short-lived cache to avoid replay attacks by the\n   broker\n7. The client notification package triggers the callback\n\nTransport and encoding\n----------------------\n\nIf the client is able to use Websockets, a secure Websocket MUST be used\nto connect to the broker.\n\nOtherwise, the client MUST run regular polling using the REST API.\n\nChannels\n--------\n\nFor every type of notification an application is able to receive, a unique\nchannel identifier is generated. The channel identifier MUST be unique to\nthe device, application and type of notification.\n\nNotifications\n-------------\n\nThe current and only supported notification format is `1`.\n\nA notification is an event published on a channel. It contains a 16 bytes\nheader as follows:\n\n    0       4       8      12      15\n    --------------------------------\n    |   timestamp   |  identifier  |\n    --------------------------------\n\n - `timestamp`, containing the current timestamp since epoch\n - `identifier`, containing the event identifier, which MUST be unique\n   per channel (e.g. incremental identifier)\n\nThe rest of the notification is the body. Body encoding is delegated to the\napplication.\n\nThe notification us encrypted using AES-GCM and the key provided by the\nclient.\n\nSecurity\n========\n\nTrust model\n-----------\n\nThe current trust model is based on the following statements:\n - the client trusts its broker with metadata related to its IP\n   address, application servers and notification count\n - the client does not trust the broker with the metadata related\n   to application (except the server IP address) and notification type\n - the client does not trust the broker with the content of notifications\n - the client does not trust the broker in regard to replay attacks\n - the client does not trust the borker in regard to DoS attacks\n - the client does not trust any third party with its notifications\n\nConfidentiality and integrity of notifications\n----------------------------------------------\n\nNotification application and type remain confidential as long as\nthe channel generation process does not provide information about\neither the application or the notification type.\n\nNotification final user is confidential to the broker as long as the\nchannel generation process does not provide information about the device\nor its owner. Confidentiality can be diminished if the broker can link the\nsource IP address to the final user.\n\nNotification content confidentiality and integrity is guaranteed by the\nauthenticating encryption scheme, as long as the key is unpredictible by\nthe broker or any other third party.\n\nA broker MUST NOT provide a list of available topics to any party.\n\nAvailability of the service\n---------------------------\n\nAny client can subscribe to new channels on the broker, as well as any\napplication server can publish to any channel on the broker. Thus, the\nfollowing limits should be applied:\n\n - client number of subscriptions should be limited\n - number of subscriptions should be limited per channel\n - client rate of subscription/unsubscription should be limited\n - server publication rate should be limited per channel\n - server publication rate should be limited in general\n\nAny client can ask its application server to publish to many notification\ntargets. Thus, the following limits should be applied:\n\n - client number of notification targets should be limited\n - client rate of creation/deletion of notification targets should be limited\n\nAny server or the broker can spam a client with notifications. Thus, the\nfollowing limits should be applied:\n\n - notification rate should be limited per channel\n - notification rate should be limited in general\n\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fkaiyou%2Facm","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fkaiyou%2Facm","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fkaiyou%2Facm/lists"}