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.
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.
@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
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
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.
@dsfgs @Mastodon