Matt Muellenweg re-comits #Tumblr to support #ActivityPub & to join the #Fediverse:
"Tumblr is...not open source yet. But we’ve said it’s going to be & we’ve tried to make the data super open. So the API’s, you can put your Tumblr into WordPress very easily, you can export all your Tumblr content... then longer term, we want to support these new protocols like activity pub on top of… We’re gonna support #RSS so things are easy to get in and out."
https://hallwaychats.com/episodes/episode-161-a-chat-with-matt-mullenweg/
@tchambers It seems like #Tumblr will not be embracing #ActivityPub for awhile. The same could be said for open sourcing Tumblr too. If I was to guess, I would say ActivityPub by summer of this year, & open sourcing Tumblr by winter (at the earliest).
What makes you expect the delay for ActivityPub?
@volkris This quote right here:
“And then longer term, we want to support these new protocols like activity pub on top of… We’re gonna support RSS so things are easy to get in and out.”
Link for those wondering: https://hallwaychats.com/episodes/episode-161-a-chat-with-matt-mullenweg/
I believe Automattic is discovering that implementing #ActivityPub upon #Tumblr is harder than expected. #MicroBlog struggles with this as well, & to my knowledge so did #WriteFreely too.
I think a lot of people have been caught off guard by how resource intensive ActivityPub is, just based on design choices that went into the standard that maybe weren't fully analyzed in terms of scaling.
I wouldn't be surprised if large platforms like Tumblr started testing and quickly realized that it was getting out of hand for their size, and they need to figure out a way to reign that in before they can really proceed.
@volkris You are probably right. I wonder if Automattic looked at the code behind #Mastodon & assumed #ActivityPub would be easy to implement inside #Tumblr‽
Well to go on about this just a little bit more, when I read the ActivityPub standard It really jumped out at me that the standard required these exponentially increasing numbers of internet connections to be opened and messages to be passed.
It's not just about reading source code, it's just looking at the design of a system that requires an instance to contact so many other instances to transmit so many copies of messages, one by one, that scales questionably.
There's just a bunch of elements where factors multiply and multiply so that as the system gets more load it has to spend exponentially more resources to address the load.
@volkris@qoto.org @darnell@one.darnell.one this is true for massive instances, if you scale horizontally the problem is manageable. As always large scale deployments have their own unique issues. This is true for all social media.
No, I have heard people complaining about it even on relatively modest instances.
I've heard people complaining that marginal increases in users on their instances led to them having to completely reevaluate hosting plans because of how quickly it grew.
That's how such exponential scaling works, though. Small increases in users leads to large increases in costs.
@volkris @nickapos I believe it’s a combination of number of users plus user activity. Some smaller instances have massive bills because the people are hyperactive on their site. Larger ones can have moderate bills because the number of active accounts is very low.
I guess in the end it’s about how much resources a server is using.
@Homebrewandhacking @darnell @nickapos
Well keep in mind also that one of the multipliers in the scaling issue is number of instances.
We should not be pushing people to start their own instances for a couple of reasons, one of which is the network effect of having like-minded people on a local timeline which is defeated by splitting them off into their own instances.
But for the sake of this discussion, the more instances the more resources required to share a post to all of the instances.
People are of course free to start their own instances if they want to, if they have a good reason to, or if they want a nice weekend project whatever. But, we should not be pushing them to do it for no reason as that is both costly and undermines some elements of the user experience.
@darnell @Homebrewandhacking @nickapos
Right but that's the difference between keeping small and keeping isolated.
Roll your own if you want to, if you have some particular reason to, if you want to play with the system yourself or if you want to do it as a hobby or whatever.
But on the other hand we need to emphasize that there is tremendous value in joining others. You lose that if you roll your own.
Absolutely! It's like...
You have "hobbyist"/individual servers.
Giant Megaservers, like .social etc
but where are the mid-range ones?
One of the known unknowns that isn't framed as a question is "how many people does my server need to bustle happily?"
I've seen 1000 posited quite frequently which seems like a heuristic from experience.
@darnell @volkris @nickapos Indeed! That's why I'm following you in part because I am interested in your takes on the matter.
Currently the fedi is sustained only on volunteer labour. To move to a costed model where people can keep the same public service ethos but also get the support they need requires information and expertise that many won't have.
Unknown unknowns are scary enough. These are known unknowns!
@darnell@one.darnell.one @volkris@qoto.org @Homebrewandhacking@mastodon.ie this makes sense, but on the other hand most people can not host their own. Also in fediverse some people will have more than one accounts in order to experienve what @volkris@qoto.org described. I have 2 more in addition to my own instance.
@nickapos @darnell @Homebrewandhacking As for having multiple accounts, it's one thing if people are having multiple accounts because they have multiple "personalities" along the lines of work versus entertainment, but people having multiple accounts so they can do things like engage with multiple instances reflects another problem that needs to be solved here.
I **think** it's a problem that can be solved at the UI level, so a problem for Mastodon and the other platforms. I'm not sure, though, and maybe it is an issue to be addressed at the #ActivityPub level.
It's definitely something that needs to be solved, though, as it really ramps up the risks around a user choosing the "wrong" instance to join. And it has major implications for the onboarding process.
Well, one feature of Fediverse and its instances is the idea that you subscribe to an instance that reflects your interests so that the local feed is people all discussing the things you're interested in discussing.
The problem is that people do have multiple interests, so some people open accounts on different instances just so they can have those different local feeds to engage with.
It would be better to bring that content to users rather than having users duplicating themselves to go after the content.
@volkris @nickapos @Homebrewandhacking It depends on how you use each account.
#Mastodon is my main #Fediverse account, but I use #Pixelfed primarily for pictures.
#WriteFreely I use for blogging (mostly web tech) & #WordPress is for lengthier posts about politics, culture & technology.
#MicroBlog I am using as an “overshare” account (where I share anything that interests me).
:) Absolutely. I don't want to _push_ people to set up their own servers. I want people to be able to look at the costings and ask themselves:
The server and traffic costs this much.
Moderation costs this much.
Therapy for moderators costs this much.
Do I really want to do this?
Currently the people most likely to set up a server are cis-white men in the tech industry (present company excepted) and I feel this has a notable effect on who comes here.
@volkris @Homebrewandhacking @nickapos I guess I am the opposite as I encourage people to roll their own instance (solo hosting) or join smaller ones & connect outwards from there.
Keeping it small is more intimate. It’s like a small town verses a metropolis. Small town are great places to live but metropolises are great places to be entertained or to work at (but not live).