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.
Well right. Except for the things that make costs go really high, costs are low!
Yeah, following lots of remote people is one of the particular contributions to costs getting out of control under the design of ActivityPub, but since the whole offering is federation, well.
As long as you don't federate your federated part of this federated system you'll be fine? Not much of a vote of confidence there!
@jan@toot.io @volkris@qoto.org @darnell@one.darnell.one it can scale fine horizontally, the problem arises when people want to host massive instances. This is a major issue for large corporations like tumblr if they want to adopt ActivityPub. Also for very large instances. Otherwise we are good.
@jan@toot.io @volkris@qoto.org @darnell@one.darnell.one I mentioned that Calckey is more efficient than mastodon and is a nodejs app. It’s going to be rewritten in rust in the future so it will be even more efficient. There is a lot of space for optimisation in the fediverse. Mastodon is not very efficient and anyone who has tried running Ruby on Rails apps in scale can testify to that.
