kentonv changed the topic of #sandstorm to: Welcome to #sandstorm: home of all things Say hi! | Have a question but no one is here? Try asking in the discussion group:
frigginglorious1 has joined #sandstorm
frigginglorious has quit [Ping timeout: 240 seconds]
frigginglorious1 is now known as frigginglorious
frigginglorious has quit [Read error: Connection reset by peer]
mokomull has joined #sandstorm
griff_ has joined #sandstorm
griff_ has quit [Quit: griff_]
griff_ has joined #sandstorm
ecloud_ is now known as ecloud
griff_ has quit [Quit: griff_]
frigginglorious has joined #sandstorm
frigginglorious has quit [Quit: frigginglorious]
griff_ has joined #sandstorm
griff_ has quit [Quit: griff_]
<JacobWeisz[m]> Apparently decentralized client apps in themselves are now harmful to the Google platform.
XgF has joined #sandstorm
<JacobWeisz[m]> It sounds like the one Mastodon client that's surviving has custom logic that prevents you from using it as a Gab client (which migrated to a non-federated Mastodon instance)
<TimMc> Yikes.
<JacobWeisz[m]> If "app can allow people to access Gab" is a violation, Firefox and Chrome should be next.
<crab> what is this Gab?
<JacobWeisz[m]> Gab is an alt-right social media site for racists banned from Twitter. Pretty much.
<JacobWeisz[m]> But they use open source software also used by a large number of other communities.
XgF has quit [Quit: - Chat comfortably. Anywhere.]
XgF has joined #sandstorm
<isd> Yeah... it's frustrating to see the rest of the fediverse being collatoreral here
XgF has quit [Client Quit]
<isd> But tusky is a decent client, so at least that's still available?
XgF has joined #sandstorm
<JacobWeisz[m]> Yeah, just concerning if Google is going to require browser/client apps include blacklists for servers they consider bad.
<JacobWeisz[m]> Particularly considering they operate the largest browser app.
<isd> I suppose for now we are "lucky" that there are a managable number of (large enough to be noticed anyway) instances for white supremecists?
<isd> But it won't scale if they spread out a bit, and ultimately the fediverse needs a better story re: moderation, or it's just going to become the same mess that email has.
<JacobWeisz[m]> I've always found it interesting that the fediverse model is interesting to two distinctly opposing radical sides.
<JacobWeisz[m]> You have the far left which makes up most of the fediverse communities I've participated in, which believes in extreme moderation and literally left Twitter because it wasn't strict enough. And then the far right which wanted to escape moderating bodies altogether.
<JacobWeisz[m]> Most people in between those extremes find themselves comfortable with mainstream platforms.
<isd> (and my personal objection to twitter of course has nothing to do with the moderation policies...)
<JacobWeisz[m]> Realistically though, I imagine the sort of folks wanting to be on Gab won't blink an eye at having to sideload a client app, but it's interesting seeing a mainstream company trying to force their moderation requirements on federated platforms this way.
<JacobWeisz[m]> A lot of the clients' official versions will probably go ahead and put in a Gab ban to get relisted on Play, I imagine.
<isd> I've probably shared this before, but since we're on the topic of fediverse moderation again:
<JacobWeisz[m]> I imagine the effective result is like Sandstorm sharing, where one person can grant the ability to connect to someone they have the ability to connect to?
<isd> yeah, I think that's what they were thinking. As I mentioned on the last office hours call, chris lemmer webber is very into ocaps.
<abliss1> "after the original success of StatusNet and OStatus in the late 2000s" *blink*
<isd> was pretty much used exclusively by foss people.
<abliss1> and that was some kind of "success"?
<isd> shrug. I think chris ws fond of their expierences from that time.
<isd> Success depends on what your goals are.
<isd> But it does seem a little over-stated to me.
<TimMc> You don't have to eat the world to be a success.
<crab> what if you're not just unsuccessful, but also really hungry?
<isd> I guess the point is, you can't really say whether something is 'successful' or not without being clear on what its goals are.
<isd> A lot of projects seem to implicitly assume success = having many users, but why? If you're a FOSS project, it's not like those users are paying you. It strikes me as some combination of cargo-culting the way for-profit businesses do things, and maybe a dash of narcisism.
<isd> or more charitibly, folks see a user base as validation that what they've built is a good thing? But I think it's worth stepping back and being clear as to what your goals really are.
<isd> So I'm not sure 'Chris was having a good time' is a worse metric for StatusNet's success than any other?
<JacobWeisz[m]> An open source project is probably successful if it has enough supporters and contributors for stable long term development.
<isd> I mean, again, it's just inherently subjective. If all you're trying to do is keep a fire burning then sure, but I mean, you were trying to stay warm or cook or something when you decided to start the fire I assume? Usually a project has something that it's trying to achieve other than just existing.
<isd> And I think not bothering to state that falls back into the for-profit norms: for a business, the goal is "make money," regardless of what the technical specifics are. SGX is a success if it sells processors, even if people spend more time writing papers about how broken it is than they do actually using it.
<isd> By contrast, if commits keep landing in Sandstorm, but nobody writes apps, I think Sandstorm would be a failure, even if "development" is sustainable. I want to accomplish something other than just making my contribution graph dark green.
<JacobWeisz[m]> I mean, I'd consider app support and development part of our project as a whole.
<isd> (To be clear, I think Sandstorm's goals are actually pretty well articulated, and they are indeed more than just keeping the engine running. But sometimes people skip over that)
<isd> abliss: pertinent to prior conversiation re: bundling an Authorization header in a URL:
<isd> (linked from the ocappub doc, but worth calling out specifically)
<abliss1> haha "Referer header", what a blast from the past. remember the good old days when a Referer Header seemed like a good idea?
<isd> No, I do not remember it seeming like a good idea.
<isd> But yeah, that's why webkeys put the token in the fragment; it doesn't get transmitted to the server.
<abliss1> i have to admit being ... bearish ... about the success likelyhood for `bear:?u=<url>&t=<token>`. The syntax just looks ugly, and there will be endless problems with escaping special characters in the url.
<isd> I think the syntax is based on magnet uris
<abliss1> but i love the idea of standardizing on some such syntax. and i'd take an ugly standard over no standard. has anyone ever used `bear:` for anything?
<isd> which is not to say that I disagree
<abliss1> i think i much prefer a syntax like the new text fragments. e.g. `<token>`
<abliss1> inspired by
<isd> So one gnarly thing about fitting activitypub into sandstorm even with ocap urls is the fact that sandstorm prefers not to show grains their own tokens
<isd> One thought that I had: what if we had a uri scheme for a "local capability?" i.e. one that was scoped to the grain, and wasn't globally meaningful. We could then have a gateway that the grain talks activitypub to that keeps track of the globally resolvable cap urls and substitutes them with local-only ones when talking to a grain.
Ristovski has joined #sandstorm
nwf has quit [Quit: WeeChat 2.9]
nwf has joined #sandstorm
<ill_logic> "DEPRECATED" collections.grains is what we were using in our code, though lots of things use it in this field
<ill_logic> Is there a better way?
<ill_logic> (A not deprecated way)