Richochet, OnionShare, WebSub, Cost savings, JSONP, OneDrive

On summer vacation tried a few new apps. Most of those, absolutely horrible code. Mostly alpha quality stuff, which is so badly broken, that you can't even say if the app is any good or not. Because it simply does not work so far. Laugh! And this is from Google Plus. Boo-hoo.
Reminded my self about current state of Richochet IM and OnionShare. Both seem to be quite light solutions, when you've got full servers, and other crypto tools running. But those are obviously easy to use in the first place. Of course you can do stuff like individually PGP encrypted (with random padding to obfuscate size) torrents over Tor when required.
This is just like the good old times. Routing from Helsinki to Strasbourg goes via New York, New York, US and back via London GB, Roubaix FR and Frankfurt DE, to Strasbourg FR. Amazing work! Tromboning at it's best! Of course it would be possible to loop via Singapore, Shanghai, Tokyo or something like that. Google routing from Helsinki to Stockholm and back to Hamina looks like a bad joke after this. Latency? Of course well over 100ms. Instead of regular around 30ms.
Studied new WebSub recommendation from W3C. Yet another pub sub stack. Yet, it's nice that there's a standard. There's just countless different parallel pub sub implementations out there. Almost every API implements it on some level. Yet in many of these cases the Hub part is left out, because the publisher more or less directly notifies the subscriber, because usually he Subscriber is like "API Client" and the Publisher is "API gateway" or something similar, endless variations of that concept do exist everywhere. I think I've written around 10 different different PubSub implementations. After reading whole documentation in detail, there's nothing new at all in this recommendation, except of course the fact that it's a recommended standard model. kw: resource discovery, subscription callback URK, specific lease duration, authenticated content distribution, unsubscribing, signed distribution requests using a shared secret, extending lease duration, HMAC challenge to verify secret. - It would be fun to write a Bottle / Flask library for this, but probably someone has done it already, so I won't bother. And as usual, it's verbose protocol with overhead, but often that's not the most important thing after all. Working, standard, easy to implement, are often much more important. Otherwise efficient purpose specific binary protocols would be wide spread. Serializing c struct isn't that hard. Yet, if this protocol is run over HTTP/2 with compression (HPACK) and persistent connections, it's quite efficient as it is. In the same sense, also XMPP is also horrible protocol.
Long term Projects: That one SAP integration project I mentioned long time ago. It's still going on. one and half years later. Or more like 19 months later. Finished? Well, not yet. More requirements are coming in almost daily. Ha. That's why some projects take bit longer than others. - Update: It's more like three years already.
Watched several documentaries about "China Engineering". They do exactly same as every other engineer. Cut as many corners and costs as possible. As long as it seems to work, if it's bit hazardous, inefficient, and assumes many external things, that happens. As long as it mostly works.
JSONP - Omg! Did we mention that codes tend to do insanely crazy and absolutely insecure things. This is just an perfect example about it. Didn't make any sense, nor is secure in anyway. But because it's hackish and it works, there's clearly a need for it. Developers, programmers, etc, people, usually love powerful stuff. Even if it often is also totally insecure. Like the bash execution escape, it was something which could have been on purpose implemented, because it was awesomely powerful way. Shellshock - Sometimes it's just so handy to implement some undocumented backdoor / way to take control, in case it's required.
OneDrive vs OneDrive for Business (ODfB) and how these are related to SharePoint? Both can run in parallel, and sync different data to SharePoint. That's so strange. Somehow Microsoft manages in making everything a mess. Not even starting the Skype, Skype for Business (SfB), Microsoft Teams rant. Also Teams chat files are stored to SharePoint. Also it seems that you can run OneDrive (not for business) client using business credentials.

2019-12-15