Ben AdidaWhat if Firefox became the best Fediverse client? Could be very powerful and timely.
http://benlog.com/2022/12/28/firefox-should-become-the-best-freaking-fediverse-app/
Builds on ideas from @luis_in_brief
Brian Smith@ben @luis_in_brief Which of those capabilities should be built into the browser and NOT feasible for an extension to implement? I’d argue that an extension should be able to do all of that, and then there’s no advantage to having the browser do it itself. Also users shouldn’t have to use a different browser to get the best Fediverse experience; imagine substituting “Microsoft Edge” or “Safari” for “Firefox” in your post.
I'm a batteries-included kinda person. Sure, make the functionality pluggable so an extension can take it over. But build it in by default. "Go install an extension" is hostile to less techy users.
As for other browsers becoming great fediverse clients... That's great! I got no issue with it. Let's compete on that front.
@ben @luis_in_brief That’s the exact argument for bundling browsers with operating systems and encouraging people to use the bundled browser. To a large extent any advantage that built-in functionality has over third-party extensions is a bug in the browser, in the same way that any advantage the built-in browser has over third-party browser is a bug in an OS.
@briansmith @luis_in_brief you are confusing emerging tech and established tech. The end goal is not maximally modular architecture. The end goal is to strike a balance of usability and user choice. In what way would my proposal reduce user choice? Maybe in 5 years when Firefox is the operating system and other extensions are fighting for relevancy :)
Right now the glaring need is more usability. Let's fix that first, and evolve the architecture later.
@ben @luis_in_brief i#In what way is it a usability advantage? Start at “I use Safari on iOS” and go through the steps to install Firefox (same steps as for a Safari extension or any standalone app, btw) through posting the first message. It can’t be any less friction for users. And it can’t be less friction for the development of the product as the browser (any browser) and existing organizational inertia & risk management are giant boat anchors.
@briansmith @luis_in_brief people installing mobile apps is a well understood concept and they can generally do it. And what's the alternative for this particular use case? Installing a different native app?
@ben @luis_in_brief First, I think the ideas in the post are great. The only point I was trying to make is that this could be done by anybody. I tend to dislike apps that are tied to a specific browser, so I prefer the idea that such things are developed independently.
I hear you, but I think in this case I'm proposing (and really only building on what Luis was proposing) that this social aspect could become an integral part of web browsing. Instead of social apps like Twitter embedding a web browser, why not have a web browser embed social functions, especially when those are built on open protocols.
Dan Mills@ben @briansmith @luis_in_brief I will add that at least the mastodon approach (have not tried other fediverse clients) leaves me wishing for some entity to act as my personal user agent.
The current architecture is shared server-centric, and it is evident to me that a team focusing on being the best user agent possible might make different tradeoffs.
1/2
@ben @briansmith @luis_in_brief several examples of this, but one: the client does not attempt to retrieve information from other servers—if I load profiles of people in my stream, they are usually empty or nearly so.
My server hasn’t loaded those posts, and maybe that’s the right tradeoff for the server. But a good client acting as my agent would realize that I clicked on a profile, please load the posts! I don’t care where they are stored, just effing do it.
@danmills @briansmith @luis_in_brief totally agreed. The crazy thing here is that native clients are inherently better than web, because of big paper cuts like the one you point out.
@ben @danmills @luis_in_brief I think the Fediverse can’t scale unless each user’s server caches and proxies profiles, images, etc. If you have 1M followers you shouldn’t have to pay for 1M image downloads; you should only have to pay for N downloads from users’ N proxies, and we must design so that N is small. So a client doing extra direct downloading would be a negative application of Postel’s law, and eventually such clients should probably be blocked at the server level as a DoS prevention / cost containment measure.
@ben @danmills @luis_in_brief similarly, ever users’ server needs to be aggressively discovering and prefetching all the replies, etc. that are currently “unknown” so that the server effectively knows everything relevant for that user. Otherwise the thread mechanics don’t work and performance & scalability are horrific. Oversimplifying a bit, but the client talking to only the users’ server is pretty much the right thing to do in all cases.
@briansmith @ben @luis_in_brief I agree about scalability considerations. But the current feature mix is… bad?
1. Identities are tightly coupled to the instance. My server is just me bc I want this identity. So server side sharing optimizations are moot anyway, no resources are being shared in my case.
2. Servers push future data to each other from the point of subscription, but don’t query old posts, even when it should be obvious to do so (profiles are empty).
@briansmith @ben @luis_in_brief so the “solutions” currently on offer are:
1. Give up on using my identity and let’s everyone join the one big server. Screw federation I guess?
2. Use the client as a sort of notification system but open threads and profiles by visiting the source in the browser every time, so that I can load the content directly and bypass my instance. This is a usability disaster, and really basic stuff doesn’t work (eg can’t click to follow)
@danmills @ben @luis_in_brief RE 1: I think most people agree that we need to agree on and deploy a separation between identity and server. RE 2: Basically that, but all that networking should be proxied through your own server, and your server should be prefetching/caching/etc. to make that fast. Again, this might require protocol improvements.
Tim Bray@briansmith @danmills @ben @luis_in_brief
>> I think most people agree that we need to agree on and deploy a separation between identity and server
I think most people don't give a flying fuck, they just want a well-run place to write and read posts. Mastodon's ability to migrate smoothly from instance to instance solves 80% of the problem and I’m not sure the remaining 20% is worth much effort. All the sovereign identity schemes are, relatively speaking, terrifyingly complex.
Diego Veralli@timbray on top of that 80%, I'd settle for a gossip-based, signature-based identity migration system, as a fallback; to have a chance to retain one's identity if an instance admin becomes hostile. I realize most people don't know what a private key is but they can probably be walked through the process when they create an account.
@briansmith @danmills @ben @luis_in_brief
@briansmith @danmills @ben @luis_in_brief
@diego @ben @luis_in_brief @danmills @briansmith
Can't agree. Civilians have essentially zero chance of taking adequate care of a private key. This is sad, because there are lots of compelling identity protocols you could use if you could assume everyone had their own private key.
Simon Brooke@timbray @diego @ben @luis_in_brief @danmills @briansmith so, surely, we need to give civilians better tools to manage private keys.
Obviously that's a partial solution, they need education too, but the current generation of high-strength key management tools are not really accessible to non-geeks.
(I strongly believe, too, that those tools need to run on the device in the non-geek's hand, not in the cloud anywhere).