61–70 of 129 posts
It 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
It 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.
Oh, 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.
It might meet with some success. To people who don't know about RSS, it's a new thing.
Is this thing russian just for me? Couldn't find a way to change the language.
Or just go here: https://refl.me/?lang=en
Earlier quoted context omitted.
My understanding is that you would be making your own. E.g. if you had a site that people could comment on, make a url that serializes those comments as JSON and then point this at that.
As pointed out elsewhere by Andrew_nenakhov, we have that already—it's RSS. Or Atom. Or JSON Feed if you really must have JSON for some reason.
Earlier quoted context omitted.
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…
Earlier quoted context omitted.
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…
Earlier 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.
From the Apple Developers Documentation [1], "On initial launch of your app on a user’s device, the system automatically establishes an accredited, encrypted, and persistent IP connection between your app and APNs."
This persistent connection is, in fact, an XMPP session (likely, a modified one) [2].
Google's FCM too uses XMPP [3].
[1] https://developer.apple.com/library/archive/documentation/Ne...
[2] https://www.quora.com/What-technology-does-the-iOS-Apple-Pus...
[3] https://firebase.google.com/docs/cloud-messaging/xmpp-server...
Earlier quoted context omitted.
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 n…