Tim Chambers
Lots of good discussion on #BlueSky and #Fediverse going on. These four questions dominate my thinking:
1. Can the ATProtocol really scale and federate? This is a very open question.
2. Can BlueSky's ATProtocol moderation work at scale? Or even NOT at scale? Blurry still.
3. Can the #Fediverse and #Mastodon improve its UX and UI experiences faster than the these first two things occur?
Lastly:
4. How quickly do robust Fediverse/ATProtocol bridges emerge?
FinchHaven
@scottjenson @dominick @tchambers
I almost don't want to enter into this, but fools rush in
"Forking shows what's possible but it's a very slow road back..."
and
"The 'just fork it' approach focuses on the easy and optional window dressing that is far less important"
You seem to be using "forking" in a very different way from what I've read over the years
"Forking" to me means the core source code - the Linux kernel, as one
You seem to be talking about UI eye candy
What am I missing?
Scott Jenson
@dominick @tchambers I see your point but I'd put it a little differently: Forking shows what's possible but it's a very slow road back to main line.
The critical point here is that the UX issues we're talking about here: better onboarding, stronger DM model, search, quote tweets are all things that benefit most from being across ALL servers.
The 'just fork it' approach focuses on the easy and optional window dressing that is far less important.
Dom DeLorenzo
@scottjenson @tchambers
I'm using Phanpy right now, which solves a ton of UX issues (e.g. making it clear who is replying to whom in a thread), but I really like the approach Elk takes to spacing, typography, lists, and account previews.
It would be great if the Mastodon team took some cues from either of these projects, but I'm happy to continue using them as my primary way of accessing Mastodon in the meantime.
Dom DeLorenzo
@scottjenson @tchambers
I've seen open discussion around UX, but it's fraught because:
1. The Mastodon team has limited dev resources and is spending most of them on improvements to security and scalability (which are arguably a higher priority).
2. Because of (1), people feel bad criticizing the UX
The cool think about Masto, however, is that it's openness allows other teams (e.g. Elk.zone, Phanpy.social) to build their own compatible UI layer on top of Mastodon.
Scott Jenson
@tchambers @activitypubblueskybridge *Is* there any discussion happening (in the open) around the UX of Mastodon? I jumped right in last October but quickly pulled back as all of the real work/prioritization was happening in house.
Florida atheist:
@Pattyagray @tchambers @upstreamism @activitypubblueskybridge
* remember when mvsk tried to back out of twttrr purchase ?
and maj. shares were already savdi * ?
https://www.youtube.com/watch?v=WYYXTGyvDmQ&t=254s
- FOIA court papers/ evidence.
and reality of ' getting free from em' all ~ @ least in FL.
https://www.youtube.com/watch?v=7y0pLdc5Two
(minus the gerrymandering mafia-cheat sys-life in so called state gov.. (abysmal .
Patty A. Gray
@tchambers @upstreamism @activitypubblueskybridge
So WHY is #BlueSky building its #AT protocol around #bigdata collection? I see big data as antithetical to #fediverse. I’m here on #Mastodon expressly to be out of the firing range of the big data obsession. My entire Internet device ecology at home is designed to foil data tracking. Why would I stay on the fediverse if I knew it was feeding into some megalomaniac’s big data obsession?
Tim Chambers
@upstreamism @activitypubblueskybridge Fully agree 👍
upstreamism
@tchambers @activitypubblueskybridge For me, the bigger question about an AP/AT bridge is how it can be (or, more acutely, whether it will be) done while still preserving ActivityPub's stronger commitment to consent and data privacy. AT is built around Big Data collection, and any efforts to bridge AP to AT need to include precautions for people who don't want their data boosted into one of Bluesky's (or an unknown third party's) indexing servers.
Jeff
@tchambers @activitypubblueskybridge Those are 4 great questions. Time will tell. I've been considering lately the contrast in approaches: Federate from the start, and confuse the hell out of most users, or Singleinstance for a while and risk unproven federation capabilities. Both approaches have advantage. Sadly, the UX/UI experiences on Mastodon make for a second hurdle for most nontechnical users.
FinchHaven
@jeff @tchambers @activitypubblueskybridge
Respectfully suggested edit:
" I've been considering lately the contrast in approaches: Federate from the start, and confuse the hell out of most users, or Singleinstance for a while and risk not being able to escape a closed system that has sole control over its (and your) DID."
Jeff
@FinchHaven @tchambers @activitypubblueskybridge Given that a DID is domain-based, isn't the most that you risk is orphaning an early repository?
PS: I like your location.. Salish -> Cascadia -> Northamerica. Same here. I will steal from you. 🙂
FinchHaven
@jeff @tchambers @activitypubblueskybridge
"...isn't the most that you risk is orphaning an early repository?"
But orphaning an early (Read: Bluesky) repository if Bluesky won't hand it over is the very crux of the whole "easy onboarding" "portable/nomad identity" which is supposed to be such big deal these days
And yeah
"Salish -> Cascadia -> North America"
Camping on Indigenous Lands
Jeff
@FinchHaven @tchambers @activitypubblueskybridge Yes, but given that Bluesky is so heavily invested in the protocols, it seems like not supporting repository roaming would be unlikely for them. Of course it is possible, but I'm treating this alpha-phase usage as disposable. Once I have my own instance, I'll invest more in the identity + history.
Jeff
@FinchHaven @tchambers @activitypubblueskybridge The users at greater risk are those who do not domain-back their identities (e.g. janedoe@bsky.social) because their history AND identity key is subject to someone else's control.
FinchHaven
@jeff @tchambers @activitypubblueskybridge
Have you read this?
Very brief, but seemingly credible:
"This is also a very interesting discussion over on Bluesky. It seems that Bluesky is really just a proof-of-concept for the protocol, and it’s not Jack’s intention that the service stick around but that other services take its place"
Jeff
@FinchHaven @tchambers @activitypubblueskybridge Indeed, hoping it is credible because it supports the vision of a fully distributed end state. I suspect the Bluesky instance will continue on OR give people a great tutorial on finding (or hosting!) the right community for themselves. This is not about a "service." It's about thousands of services.
Osma A
@jeff
So far, what we have is a random key in someone else's closed source database, a random key generated by a closed source application inserted into a DNS record, and a text string matching said DNS record in aforementioned closed source database.
It is hard to see which part of this makes it less proprietary than a text string which does not match a DNS record.
Jeff
@osma @FinchHaven @tchambers @activitypubblueskybridge Actually, so far we have a documented protocol, being developed open-source (https://github.com/bluesky-social/atproto, /indigo, ...) with a very early reference implantation atop that protocol.
If you're point is to write off the potential of the protocol based upon an incompletely initial service atop it, I can't argue with you.
Osma A
@jeff
At no point did I "write off a protocol". If you're trying to say a published protocol spec somehow reduces the risk of current user content being locked in to an orphaned, currently-private prototype implementation that has no existing migration path, you'll need to be clearer about your arguments.
@FinchHaven @tchambers @activitypubblueskybridge
Patty A. Gray
@Brownian_motion @volkris @tchambers @upstreamism @activitypubblueskybridge
Sorry, I was busy IRL for a few days, but I’d like to reply by saying I wish you would refrain from being insulting here on Mastodon. I don’t need a tin foil hat, thanks. Discussions here are freewheeling, but I don’t welcome strident proclamations.
Brownian_motion
@volkris @Pattyagray @tchambers @upstreamism @activitypubblueskybridge https://qoto.org/@volkris/110324073813028931 People really need to get a tinfoil hat. Anything we put online (and ALL of the metadata) IS GOING to be recorded and analyzed by someone, for some purpose, and USED BY THEM when, where, and how THEY want to present it.
volkris
I think it’s really important to reply to comments like this to raise awareness that #Fediverse is absolutely not outside the reach of #bigdata collection.
In fact, given how the core protocol is set up with few privacy controls, it arguably makes #Mastodon content even more likely to be vacuumed up by big data.
People need to realize that they have only limited control over their content here. Anything they put in is effectively broadcast to the world, no matter privacy settings, and if you’re worried about big data, well, big data operators are happy to vacuum that up.
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.