Message from @Undead Mockingbird
Discord ID: 507849370566262784
not on mainframe, which is problematic as well.. imagine kiddie porn shops that setup on mainframe and can't be stopped etc
Technically, if BitChute was forced to "delete a video", the tracker that they use, which I believe is public, would still list the video and you could continue sharing it, with the same magnet link, but the video posting itself would be gone from the BitChute site, i.e. it would no longer show up for the user's channel or show up through a search on the BitChute site, because control over that is in BitChute's hands.
However, then you might as well simply share your videos as torrents. You are still basically deplatformed from BitChute, if they gave in.
I cannot think of a single framework that is like a web site where control is 100% decentralized, but maybe what you just posted is such an exception (reading now).
yeah what i posted is it
apps can be built on it that are unstoppable
As for Mastodon, I actually really, really like the concept. GNU Social is even nicer. It seems to have made a very conscious decision to use very established web concepts, such as using digest authentication (the one where you can embed user:pw in the URL) instead of something fancy like OAuth.
i just hate any system having human moderators
always bias
always exerting control
The API is incredibly simple, with posting an image, for example, being a simple HTTP POST, returning an ID in JSON, and you can then reference that ID in a post to attach it. It's the simplest API I have programmed against so far, out of Mastodon, Gab, Minds, Steemit, Twitter, and Facebook.
but it can be censored right?
someone is in control
Hmm ... let me think.
Yes, the isntance admin could censor.
"Our unique network design prevents data from ever being tracked or censored. dApps continue to live on Mainframe whether governments, tech giants, or we want them to."
Federation is controlled through a central repository, with many instances already blacklisted.
But, federation "only" affects whether or not posts of one instance show up on other, federated instances.
Wait, let me re-read some source code.
gotta run for now, interesting stuff tho
Ah, here it is. I was wrong. It uses HTTP Basic authentication.
So, it's by far the simplest to program against. Basically made to rely on only the most basic, old school web protocols.
i'd rather have oauth tokens with scopes ¯\_(ツ)_/¯
Yeah ... hmm.
Well, it has its use, of course, or nobody would put in the extra effort, but it's nice having basic auth.
also
> fucking xml
xml?
Oh, right! Now I see it. I thought it was JSON.
you send json, endpoints return xml
Wait ... it is JSON, but also XML. That's weird.
i'm wrong, you just send params
Ah, I remember. For some reason, I got XML in one call and JSON in another. I have no clue why.
It seems weird to me.
When posting an image, you get XML.
actually dunnolol, fuck it i'm tired ¯\_(ツ)_/¯
When posting a status, you send JSON.
Maybe I was using the endpoint weird, but the code is tested and I've been using it for a while, so at least it works. But I might still be needlessly complicated about it. Not sure - I reverse engineered it in the web debugger, because I was too lazy to read the manual. lel
Ah, and you mentioned OAuth: I guess you need it for three legged authentication, i.e. web applications authenticating you to the social media service on your behalf, without having to give away your credentials, just the way when you authorize an app to post to Twitter or Facebook.