Would you tolerate a corporation stealing limited resources from your land (that should probably #stayInTheGround we might add)?
Up to 1,000 #USA troops are in #Syria, occupying #oil fields and river crossings. The Syrian Govt has repeatedly protested that their presence violates #internationalLaw.
We expressed opposition in 2015 on '#FalseBook' to the #incursion to #pillage. Though we were widely supported by followers in #Australia, F'book attacked.
We oppose #CAGEMAFIA for solid reasons.
BTW it looks like this little instance will be the next one forced to shutdown.
Paying of bills are a #goingConcern.
We've had:
1) one response to our #FDroid dev-for-donations offer (only to question our proposal),
2) no response to our idea to help #OMN to keep it online.
Server is managed by the exact same people as the 'activism' server we were on (hosted by @mastohost and moderated by @msaunders, Hamish and co), but this instance was more for #campaigning rather than #activism.
It seems @Mastodon is recreating legacy #socialMedia with a "#decentralisation ability". The #Fediverse being a vehicle on which to test it.
Decentralisation in M'don is often a smokescreen. The use of #CDNs is rife. Something like #GlutPlug/#I2PFS is needed for genuine #sustainability.
The trend?
"#MakeFediverseMastodon" — make it impossible to serve without a massive #datacenter. Thus forcing a return to #BigData, algorithmic feeds, #massSurveillance and overall repression.
Before we even joined Fediverse in 2019, we sensed that something was not quite right about the Mastodon story. We joined a mastodon server in the hope that in good faith we might help guide development, towards protocols like #I2P that empower the user.
Needless to say, all our suspicions have over time been validated.
Grave times for #communication.
The thing is, this platform was not designed to actually be decentralized. To its core, this platform is centralized around instances.
In my opinion, that's not quite right. There are a lot of problems with it. And I do criticize it every chance I can.
@dsfgs @volkris @Mastodon @msaunders
I think as someone which has looked into the tech a bit I should elaborate
Federated means Decentralized, but not peer-to-peer.
Essentially, the difference between server-server decentralization and client-client decentralization can mean a lot, but it doesn‘t make Mastodon and the Fediverse any less decentralized than something like Nostr, but the model is different and both have their pros and cons when compared to one another.
@Rush @volkris @Mastodon @msaunders
Yes, but federations also require work done by citizens to survive, which is where something like #I2PFS or GlutPlug comes in.
The idea is the server acts as a conductor saying, "I'm busy but this @i2p'er will have video". So when min two #I2P'ers have posted, boosted or commented on a post with content and are known to have downloaded the content, then at random the server picks one to serve it. This depends on a minimum battery power of I2P'er, say 33%.
@Rush @volkris @Mastodon @msaunders @i2p
If each I2P'er has 3 addresses and a minimum of two I2P'ers are needed to trigger serving content over I2P, then a minimum of 6 addresses are in use for a resource. It becomes very difficult to even learn even who is serving you the content. This privacy benefit translates to #security and #sustainablity of the service.
Its like people chipping in to help out at the local library. It needs to happen in the real world, so why not on fediverse?
Well, it's not really about peer-to-peer since in the ActivityPub model all of the instances stand as peers.
I'd more say it's not user-to-user.
But it DOES make Fediverse less centralized, which we can see from the protocol talking about instances managing their centralized content feeds to the user-facing implications like moderation.
All users on an instance are bound by the single set of administrative decisions made by the instance operator, the one, central node of processing and configuration.
And the one, singular point of failure the instance represents.
Sure, a person can leave and join a different instance, but that's just going from one central operator serving one group of users to another.
So yes, this does make Fediverse less decentralized than some alternatives, and IMO it makes it not particularly decentralized at all.
It just makes for more centers.
@dsfgs @Mastodon @msaunders
@volkris wdym there's plenty of instances with a bus factor over 1
@Rush to put it simply, every instance with more than one user is a centralized collection of users.
And there are plenty of instances with more than one user.
@volkris
This is one of the _key_ reasons we're developing the #OGB ;
a core idea being that these spaces should be communally run.
Of course some people will still opt for the BDFL model (lack of benevolence should(could?) spur migrations).
It boils down to lack of community and cooperation, imho.
If we don't develop those tools, instead opting for more narcissism, then I expect to continue to see protracted discussion about symptoms rather than causes.
@msaunders and I completely and utterly disagree with that approach.
It strikes me that the approach is one that makes a mistake of confusing technological and social problems, looking for social solutions to technological problems and technological solutions to social problems.
I don't think it's good for the platform, and I myself would have no interest in it.
I think the platform would be much better focusing on empowering users than empowering any sort of group, because the group think is what got us to the complaints about Twitter, etc, in the first place.
The lyrics of the song escape me this evening, but welcome the new boss, same as the old boss?
@dsfgs I think a lot of your reply both describes symptoms of not being truly decentralized AND reasons I criticize that point.
So that's why I emphasize the issue that ActivityPub is not really decentralized. **Federated**, sure, but centralized around instances.
And I emphasize the lack of decentralization as part of trying to oppose that potential of further centralization.
When you talk about S2S you're actually highlighting centralization.
Users are corralled into instances. Those servers become central points of failure; users are under the thumbs of server administrators; all interaction with the system is collected into inboxes and outboxes there on the servers.
ActivityPub is designed to be centralized around servers. When you mention server 2 server communication, you're emphasizing exactly that centralization.
@dsfgs @Mastodon
@volkris
My intention was to highlight that the S2S part of ActPub protocol could be used to implement P2P, one instance per user.
But I was wrong to say the the spec was written with "full decentralisation" in mind.
You're right that there is still the mindset of centralisation as long as we have server to client relationships.
@dsfgs @Mastodon
@msaunders and there is the additional issue of the inefficiency of AP.
The way it's designed, it scales by number of instances, not by number of users, and we've already seen a whole lot of complaints about the resource consumption. It involves as it scales.
So another criticism of the platform is that the more we promote one user instances, the more resources it's going to consume.
So even that is not a particularly good path to decentralization.
@volkris
Agreed, endless growth is endlessly stupid.
Which is why there is cause for developing community governance.
We would have to effectively build "traditions" that do things like encourage a max instance size, and calving beyond that point.
There's nothing inherently wrong with centralisation or having community-run "centralised" servers as long as limits to scale are respected; ill-conceived scale is at the root.
@volkris
Fully decentralised P2P is preferable to me, but the data storage problem is still ridiculous (as with C2S but exacerbated) - and the tools don't yet exist for each peer to reason and make decision about such things - "normal" people just want shit to work (even though it rarely does).
And again, with P2P the tools for community self-governance are needed, or it just continues to add to the mess of people shouting into the void.
@msaunders @volkris @Mastodon
Whether this is about ActivityPub or not is of little consequence to us. All we see is that without some level of #participation/input from peers to help serve specific content (images and video), it is quite obvious that the #Fediverse will trend back towards re-centralisation.
We call on #I2P developers to explore how they can make something like #GlutPlug work in fediverse clients like #Tokodon (possibly #Fedilab too, but #AllPhonesAreBad so maybe not).
@dsfgs sounds like you're really embracing ignorance, demanding something while proudly lacking the background to really understand what you're asking for.
It's... not a productive stance.
@msaunders @Mastodon
@volkris @msaunders @Mastodon
What we are saying is that if Activity Pub does not have a P2P element, such as what we have described, then it will trend back to re-centralisation.
Yes we are not in a position to read the full ActivityPub spec, call us ignorant if you like but we stated what we meant. We qualified our stance.
@volkris @msaunders @Mastodon
Our understanding is that the #ActivityPub spec is not the be-all-and-end-all. That Mastodon have gone and trailblazed over it.
So you didn't like our stance, you might also not like what #Mastodon have done. :)
So what I'd say is that no, ActivityPub is not P2P, and that's based on design decisions made long ago, that it would be pretty hard to change now.
AP was never meant to be decentralized. Instead, it embraces centralization, just centralization around instances. I always push back when people describe fediverse as decentralized. It's not.
I have serious criticisms against ActivityPub. But at this point it is what it is.
At this point, making the platform P2P would require such huge changes to the standard that one might as well just jump to a different platform that already works that way.
I know I'm interested in that.
@volkris @msaunders @Mastodon
Its a matter of perspective. Remember there's '#decentralised' and then '#distributed'. *wink
We think it's possible to adapt fedi to the worsening scaling problems. We think it'd only require 7-10% of fedi users serve via a GlutPlug'ging system for it to be effective. It seems you don't think it can adapt and would rather "jump to a different platform that already works".
What are you thinking is that better platform? Genuinely interested.
@dsfgs I'd say it's federated versus decentralized. Under this protocol, under this design, this is federated, a bunch of centralized servers trading content.
As for better platform, meh, there are who knows how many stubs of platforms out there that are more decentralized, but without critical mass they just don't matter for a social media platform.
Like anything else in technology, better engineering doesn't make for a better platform if it doesn't happened to be the one that catches on.
I mean Facebook is nothing but mediocrity, but it reached critical mass so it succeeded.
@volkris @msaunders @Mastodon
Exactly. We can't throw baby out.
We reiterate that @Mastodon implemented things without them being in the #ActivityPub spec. We see GlutPlug as something similar, ie. include GlutPlug'ed links to content to instances and its up to them to serve those to users.
Interested to know what other admins like @AusSocialAdmin, @lain and @SDF think of a P2P-content-delivery ability over I2P.
Even the slowest moving codebase, Bitcoin, supports I2P for **years** now. 🙂
@volkris @Mastodon @msaunders
Yes and no, we meant decentralised as compared to the legacy offerings.
The way Master'don will trend is back torwards #reCentralisation, because of the #contentDelivery issue.
iwrc, some instances don't try to serve all content and #hotLink(?) to the originating instance, but that has issues too, incl. #privacy.
That's why we suggest servers play a #conductor's role. With a #glutPlug they'd hotlink to I2P hosted content served by fedizens who boosted it.