@bazbt3 it was a sad message. Made me qq.
// @thrrgilag
@jextxadore nice! I had a class on Stouts this afternoon, but we only tasted stouts made by my brewery. :P
@thrrgilag For a little service like mine, I don't think it's worth it. Complicated, very bad to get wrong, have to open source my material, extra processing, and I'm just not sure it's where my service exists for users. Most of the content is public material. A client could encrypt the data instead, like Ravisorg did.
// @matigo
@matigo nak, that may come later, but I won't implement encryption without professional help.
@matigo @sumudu @streakmachine Yeah, it's very similar. Not just the the API URL, but it would take an hour on an in-depth client to switch around API endpoints and realize what was happening, fix it up, and be running.
@tomas yowza! It's a monster! :DDD I'm all for you pushing ahead, but in an ideal world those three streams would be read by one server, which would spit them all out to clients individually, I think… so you don't have to reload three streams all by one browser (lots of loading going on!). But if it loads slowly, or manually, maybe it doesn't matter. But it doesn't matter anyway! Go forward!
@hybotics You're writing a server-side client for anyone to use, not just yourself? Then the server should make the call. It'll redirect the user's browser to an authorization page, which will then forward back to your app.