Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Federated App Problem

plug-world.com

Post reply on HN
Print view View original

101–110 of 201 posts

Re: The Federated App Problem

#101

Post by Pathogen-David »

copperx wrote: post #66
jacooper wrote: post #15

I think the only reason people know about email supporting multiple providers is because its old, if email was made today, you bet its going to be centralized. Heck people already scratch their heads when an email isn't hosted @gmail.com or @hotmail/outlook.com. And the learning curve exists because unprofitable companies like Twitter and Reddit made centralization possible by burning money, the old internet was dece…

> Heck people already scratch their heads when an email isn't hosted @gmail.com or @hotmail/outlook.com. What people? Are they in the room with us right now? Anyone that works at a small/medium/large company has an email address @company.com

Except most normal people don't use their corporate email address for personal stuff.

I've always used a custom domain for my main email addresses and whenever I've had to give it to someone else verbally it inevitably leads to some amount of confusion. At the very least they get thrown off by the fact that I didn't say gmail/outlook/yahoo after the @ and I have to repeat the domain name.

Re: The Federated App Problem

#102

Post by bawolff »

Honestly these all seem like solvable albeit hard problems.

Learning curve is a ux problem. Yes federated is a bit harder, but i think this is more the general problem that open source is terrible at ux, especially when it doesn't have sonething to copy, not a fundamental federated issue.

(Cross-instance) Authentication - definitely hard, but seems solvable as well. Whether with fancy crypto or maybe some federated oauth thing.

SEO - meh, who cares. Do people really use these sites for googling. Also seems like could be solved by getting everyone to shove some rel=canonical all over the place.

Personally i think the fundamental issue (as opposed to just engineering challenge issues) is that its hard to modify/adapt federated protocols. I very much agree with moxie's critique of federation at https://signal.org/blog/the-ecosystem-is-moving/ . Everything else is a simple matter of programming - an inability to rapidly iterate is on the other hand is an unsolvable problem.

Re: The Federated App Problem

#103

Post by maeln »

Kiro wrote: post #99

Mastodon (and Lemmy) had the opportunity of its lifetime and failed to capture it. It honestly feels like crypto with lots of smart people wasting time on a doomed concept.

I feel like we are comparing apple and oranges here. Mastodon and Lemmy are free project, run by a community and, in the case of Mastodon, backed by a non-profit. Depending on who you ask, they don't really give a damn about capturing the opportunity. It is not a for profit venture where capturing new user is essential and critical. It is about creating something they think are cool, neat and want to use.

Re: The Federated App Problem

#104

Post by bobsmooth »

ikt wrote: post #100
bobsmooth wrote: post #65

Earlier quoted context omitted.

Try loading up an image on a different instance, or browsing that instance from a different instance. If you can figure it out, it's as slow as molasses.

Fosstodon posts that are on my home feed from other instances like this: https://imgur.com/6ToDHHm which is from floss.social load up instantly Looking at the image source despite it being uploaded to another instance it's hosted on Fosstodon: https://cdn.fosstodon.org/cache/media_attachments/files/110/... That said when I see posts linked to Mastodon on HN I do notice that maybe the HN Hug of Death hits them hard as…

I'm sure it's fine if both servers have the resources but visiting a small instance from a different small instance and all the images load really slowly.

Re: The Federated App Problem

#105

Post by pluto_modadic »

nkuttler wrote: post #94
armchairhacker wrote: post #39

A big problem is that you don't actually see content on other instances. Also, you can't link accounts between instances (EDIT: you can post and subscribe to communities on other instances, but it's not obvious. You can't link 2 accounts on separate instances though) There are several rust instances: https://lemmy.ml/c/rust , https://programming.dev/c/rust , https://lemmyrs.org/ , and probably more. Why aren't they l…

> A big problem is that you don't actually see content on other instances What do you mean? On lemmy you simply click "all" and see a feed from all federated sources, on kbin that seems to be the default. When you open threads/posts you see comments from all sources. The other stuff doesn't exist yet as the platform is very new. You can help.

this isn't strictly true and the weird edge cases add more mental energy than conforming to the expectation of "all of the content I was expecting".

For example, clicking on one of the profiles I follow, and then their followers. This will only show the profiles I also follow on that remote server. Do that again, and it gets even worse.

Where instead, the "thing you expect to happen" is to list, 1:1, their follow list as it exists on the remote server.

Other things, for example, not fetching someone's post history earlier than before you followed them, when you're browsing their profile. e.g., a user with 100 posts that you just followed.

I'm aware of the technical reasons (you weren't subscribed), and the open source reasons (not enough volunteers to fix the bug); but both are inadequate to a new user, frustrated and lonely, struggling with a lack of network effects, where having a delightful app might save that experience.

Re: The Federated App Problem

#106

Post by TeMPOraL »

class4behavior wrote: post #20
sxg wrote: post #4

I agree with the premise of the article. I’m a new Mastodon user trying to give the platform an honest shot, but I can’t understand why I would choose any particular server over another. Why choose anything other than the pseudo-default Mastodon.social? If I’m forced to choose another server, is that choice actually meaningful? I feel like I’m randomly picking between Hachyderm and TechHub.io and others. One advantag…

The same way people manage to decide whether to buy buns at the bakery on the right rather than the one on the left or donate to the NGO1 rather than NGO2 doing exactly the same, you ought to manage to judge which instance is a better fit or if it even matters in your case. >why would all problematic users congregate on the same server? Isn’t it far more likely that you’ll have to block individual users across numero…

> The same way people manage to decide whether to buy buns at the bakery on the right rather than the one on the left or donate to the NGO1 rather than NGO2 doing exactly the same, you ought to manage to judge which instance is a better fit or if it even matters in your case.

Bakeries and NGOs aren't sticky. Your relationships with them is a series of one-time transactions, and at any time you can switch to the alternative at no cost.

Picking a Mastodon instance is more like picking a school or university - it's a choice of where to commit, made at a point when you're least equipped to make a good call, and increasingly hard to reverse the longer you go along with it.

Re: The Federated App Problem

#107

Post by stereolambda »

If the goal is to talk about your interests with strangers (and not pull in your whole family and political and journalistic class), some minimal federation friction could be beneficial actually, as a soft filter. Maybe it's worth it to have some common pre-Eternal September spaces on the Internet, even it means not building unicorn empires.

The latter seems to be a mindset people aren't able to shake off for some reason, applicable to the given case or not. If a person can write and read two sorta coherent paragraphs of text for a internet forum, they are already on the level of being willing to learn and a little curious, above what the tech giants expect from their model user. There are enough of such people to have interesting and diverse discussions. Don't tell me Discord is easy to figure out. I'm not saying the devs should be working to make the experience easier, but it starts to be one of those topics where the discussion is meme-based.

You can tell search engine robots not to index your copies of different forums. I don't think they are viewable by default anyway? Avoiding small instances to avoid outages sounds like 4D strats to most users, who might prefer cosiness, personal connections and camaraderie, like on Minecraft servers, say.

Re: The Federated App Problem

#108

Post by geppetto »

sxg wrote: post #4

I agree with the premise of the article. I’m a new Mastodon user trying to give the platform an honest shot, but I can’t understand why I would choose any particular server over another. Why choose anything other than the pseudo-default Mastodon.social? If I’m forced to choose another server, is that choice actually meaningful? I feel like I’m randomly picking between Hachyderm and TechHub.io and others. One advantag…

Easy, I just choose the instance with the bigger community in my own native language then added people from other instances.

Re: The Federated App Problem

#109

Post by INTPenis »

I thought this would address the scaling of federating activitypub messages, but it's really just problems from an end user perspective. Those problems we can easily solve. Mastodon auth is already a thing, allowing the same app to authenticate against multiple types of backend software, and oauth can also be enabled to use a central identity.

When I hosted a fedi node I disabled search engine crawling with robots.txt, but it can easily be enabled.

Learning curve is all about giving it time and earning experience in accessibility.

But regarding the scaling out of messages; I am writing a small activitypub app in Python, because it's just so fast to prototype in, but I want the option to rewrite heavily used components in another language. So instead of passing pickled or serialized Python/Ruby code around background job processing, I aim to only pass ActivityStream objects, simple JSON that is language agnostic.

Just put it in different queues depending on its destination. Then any background job processing program can process the queues and put the data into DB, or whatever needs to happen.

Re: The Federated App Problem

#110

Post by _lnwk »

audiodude wrote: post #69
copperx wrote: post #66

Earlier quoted context omitted.

> Heck people already scratch their heads when an email isn't hosted @gmail.com or @hotmail/outlook.com. What people? Are they in the room with us right now? Anyone that works at a small/medium/large company has an email address @company.com

I've heard plenty of stories of people saying "my email is fred@fredsmith.com" and it being input by a customer rep as "fred@fredsmith.com@gmail.com". Or them asking "At gmail.com or hotmail?" and you have to explain "No, at fredsmith.com".

I use some Polish email provider - the amount of times websites say my email must not be valid because it's @[service].pl was way too high :(
Post reply on HN