Jump to content

radCM: A flexible alternative to GCM and APNS using XRPL


Recommended Posts

As a mobile developer maybe you needed to send your user a notification from your server backend to his smartphone. Therefore you probably used Google Cloud Messaging (GCM) and/or Apple Push Notification Service (APNS). While it’s easy to send notifications to user’s smartphone, it’s getting harder if you like to send a notification from user’s smartphone to his computer. Existing services have limited functionality for that use case or don’t support all desired computer platforms. Therefore we created radCM as a new approach using XRPL.

It's the first paragraph of this Coil post. What do you think about that approach?

Link to comment
Share on other sites

You should consider using BSV as your backend. They specifically target usecases such as yours. Higher performance, low transaction costs, infinitely scalable.

XRPL transactions will become too expensive for your usecase when the usage goes up, and for messages, 3 seconds is really too long. XRPL gives you transaction finality after those three seconds, unlike BSV (and therefore beats it out of the park for big payments), but that does not seem to be a benefit for your usecase.

Link to comment
Share on other sites

I don't think that this is a very good use case for XRPL. Yes, it can be (ab)used in that way but it only works because nobody does this at scale. If they did, you'd likely no longer have free and open access to on ledger data and especially memos just like that because you're leeching public resources which will push back if they are used in that way.

Link to comment
Share on other sites

Thanks for your feedback. The usecase is blockchain agnostic. An implementation could also use other cryptos like Nano. Important are tiny/free fees for transactions and speed. I used XRPL for convenience :)
Totally agree @Sukrim, this usecase is some kind of an abuse of a payment system for a messaging system. I like trying out new usecases that do not always fit what it’s meant for. It does not care about amounts or settlement. It just uses its messaging feature. I also think, relying on ledger access is a main critic point. It shifts maintenance cost from myself to the entity that provides ledger access. Despite that, I see following main advantages:

  • It's a kind of outsourcing infrastructure. I prefer paying someone for ledger access, rather than caring about a more complex backend infrastructure myself with maintenance.
  • Backend can be a simple PHP script (simple POST REST API). Hosting a PHP script is very simple, doesn’t need much server maintenance and often available almost (or complety) for free. On the other hand, with direct WebSockets we need something like a Node.js on the server side. That comes with a lot more "admin work" than hosting a PHP script.

Another critic would be “why not pay someone to use a generic push notification service, instead of building something yourself”.

I appreciated your critical feedback, thanks again

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share



×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.