Oh, I finally understand it! It is just an RSS (but with JSON instead of XML)!
I guess but that already exists https://jsonfeed.org/version/1
Messages via JSON
51–60 of 129 posts
Re: Messages via JSON
#52Earlier quoted context omitted.
Because it is the most inefficient approach possible. You either have potentially long delays before receiving a notification (if you poll service once an hour, average delay would be 30 minutes), or you do LOTS of polling, draining the battery/abusing the service. If you have 20 notifications / day and you check service every minute, in a day you'll make 24*60 poll requests, only 1,38% of which would yield some mean…
And yet, this is exactly how push notifications are implemented on mobile phones. You have the illusion to push a message from server to device while in fact you also push a message onto a queue that is polled at regular intervals by the mobile. No way around it, mobile devices don't have guaranteed connectivity as servers do.
> No way around it, mobile devices don't have guaranteed connectivity as servers do.
Not sure what "guaranteed connectivity" has to do with it, your phone is connected to network ~90% of the time, and when it is, it has a socket connection with the Google Cloud Messaging API (or iPhone equivalient) which pushes down data as it comes into the queue. If messages come in while you're disconnected, you get them all the next time data is pushed.
Re: Messages via JSON
#53Is this thing russian just for me?
Couldn't find a way to change the language.
Re: Messages via JSON
#54> Request signature format(crc): [time_stamp]_[md5(time_stamp+secret_key)] This should probably be an HMAC construction at the very least, and MD5 in general just should be discarded entirely in favor of BLAKE2b, SHA-2 or SHA-3. And ideally, it'd actually validate the rest of the contents as well.
There's another problem, if the author tells us that this is crc, while it's a MAC (not particularly strong tbh), it shows that we, as developers and users, cannot trust that cryptographic decisions of the author are of any consideration. For reference, crc is not a signature, its full name is "cyclic redundancy check", which is a really simple mathematical operation, that computes a specific remainder that comes fro…
>we can find another string that differs in one byte only, that has the target crc
reading that has me curious; if one can do that for any arbitrary string, and then iterate that process, doesn't that stand to reason that with enough work, one could make any two given strings calculate out to the same crc? I guess maybe not because that one byte constraint isn't specified as far as where it occurs and whether it's an insertion, deletion, permutation etc, but the way I see it if you can do it with one string to another, you could likely keep chaining that indefinitely and get countless strings that come to the same crc.
sorry if this is old news or anything I was just struck by that thought while reading your comment
Re: Messages via JSON
#55It would be cool to see a directory of public JSON feeds you can subscribe to - weather notifications, sports data, transit delays, etc. You could also have premium feeds that require a subscription.
Like RSS, but better
There is a nice substratum of curl services, like wttr.in or getnews.tech that follow a similar concept
I hope this is the beginning of a gopher + JSON + curl services era
Re: Messages via JSON
#56What exactly is new in this ? Isn't this what Android and iOS notification services do ? And all messaging services ? What did I miss
True enough, this is in concept the very same as Apple Push Notification (APN) service. Difference is that you are in charge of the server side and handle all the security and uptime yourself.
Very cool idea, simple enough to generate a lot of really cool projects.
Re: Messages via JSON
#57Oh, I finally understand it! It is just an RSS (but with JSON instead of XML)!
As far as I can tell, that's it. It's a reinvention of RSS without any notable advantages and no compatibility with existing systems.
So, a reinvented wheel that doesn't work on roads.
Re: Messages via JSON
#58Earlier quoted context omitted.
It's a mobile app that polls an endpoint for json, after the user configures it (seemingly with a QR code), that's all. There's no middle-man server, and it's also not push. Neat idea, low barrier to entry. Can't tell from docs how authz/authn are handled.
And who maintains the message queue until the client pools next(the service provided by these middle-man servers) ? And what about message by user identifier ? And client app will eat my battery because one more service is constantly polling now ?
You can configure the refresh interval in the service response: https://refl.me/docs
Would be nice if you could override this client side as well.
Re: Messages via JSON
#59Im not getting notifications with the test_crc endpoint. Key is correct, Pixel 2 Android 10 latest version.
Re: Messages via JSON
#60What exactly is new in this ? Isn't this what Android and iOS notification services do ? And all messaging services ? What did I miss
The difference between push and pull.
Push notifications function on the principle that when a state change happens, the notification is pushed to the device.
Pull notification is when device polls some service for data, detects change, and then emits notification if change has occurred.
There are benefits and drawbacks to both.