The Fediverse is sufficiently broken that as a developer one feels that one can only make it better.
Posts
-
Second question: I’d like to know your thoughts. -
If I build my recipe sharing app for the Fediverse (see fediverse-ideas 44), I would not expect Mastodon to have to change in order to support it.If I build my recipe sharing app for the Fediverse (see fediverse-ideas 44), I would not expect Mastodon to have to change in order to support it.
I also firmly believe that: "Helge is able to create a recipe sharing app for your network that interoperates in a sensible way" is a criteria for if your network is good.
If your social network is specifically targeted at recipes, use "making animal sounds" instead. Being able to moo is important too.
-
Adapting something about monkeys to ActivityPub: For every possible usage of an ActivityStreams object, there will eventually be a developer that does so.Adapting something about monkeys to ActivityPub: For every possible usage of an ActivityStreams object, there will eventually be a developer that does so. And it's all fine with the specification! 🥳
-
I think "Counting the number of request" necessary to do something is a good idea to get an idea if things work.I think "Counting the number of request" necessary to do something is a good idea to get an idea if things work. It is like the infamous back of the envelope calculation from physics. It's a quick method to get an idea what is going on. Often the answers are correct.
As an example, due to me reading about it again, that ActivityPub Client To Server as specified. In order to see if there is new content you need to make a request. So if you want to update the content of your client every 10 seconds, you are making 6 requests per minute. If you use technology such as websockets, you are left with 1 request total.
-
Did you see my last message, i will close activitypub in my main channel and leave only zot nomad.If memory serves me correctly, Mastodon has a "thread unroller" based on the replies property. This means that if "replies" is an URI and not an embedded object. This URI will be fetched. There is then some follow up logic to decide to fetch further posts. I've not dug deeply into it.
Also Mastodon always fetches the replies collection when I post and host done so since I implemented it.
-
Reading a bit more about ActivityPub again, I would like to offer you my summary of the situation:The replies collection only contains direct replies. So if post A has a reply B and B has a reply C. This means that A.replies = [B] and B.replies = [C]. So you will need to fetch A, A.replies, B, B.replies, C, and C.replies in order to ensure that one can gets everything.
Depending on how one reads replies, I'm sure somebody will argue that C should also be in A.replies. It's just not how Mastodon implements stuff at this moment.
-
Reading a bit more about ActivityPub again, I would like to offer you my summary of the situation:Reading a bit more about ActivityPub again, I would like to offer you my summary of the situation:
- ActivityPub is good at sharing updates with your friends, i.e. POST to inbox
- ActivityPub/ActivityStreams is pretty bad at everything else.
For the second statement: Consider fetching a conversation from Mastodon's ActivityPub implementation. Assume that the conversation contains N Notes. With an implementation optimized for Mastodon it takes: 2 * N requests. With a general implementation that doesn't assume Mastodon's quirks. It probably takes 4 * N requests. This doesn't give you Like/Share counts.
If you had a good protocol, it would take 1 request (or something that doesn't scale in N).
Finally: I don't consider the thing hard to fix. There are solutions floating around for people that are looking. The problem is more in making everyone aware of what one needs ...
-
RFC 9620: Guidelines for Human Rights Protocol and Architecture ConsiderationsI want somebody to write an analysis where #ActivityPub, #AtProto, etc pass/fail at these guidelines.
Has somebody done this?
-
I think people designing the next generation of social media protocols should look at extreme cases: One should aim for the protocol degrading nicely towards both static sites and thick clients with no server backing them.I think people designing the next generation of social media protocols should look at extreme cases: One should aim for the protocol degrading nicely towards both static sites and thick clients with no server backing them.
There are obvious caveats: You cannot expect a static site to show the reply, you made to an article there. Nor can you expect to fetch data from a thick client.
-
maybe a hot take but it ought to be possible to reply to a post without delivering your post to the author of the post you replied to.AFAIK ActivityPub et al. don't contain any restrictions on
inReplyTo not null
implying something about the recipients.Maybe you need to use a better implementation that allows you to edit the recipients. ActivityPub even states here "https://www.w3.org/TR/activitypub/#client-addressing", so being able to reply to a post without addressing the author is a suggested feature.
-
Am wondering if it'd make sense to have a dedicated Reply activity, such that a reply becomes Reply(Note) instead of Create(Note)Just to say this again and again: I don't think that ActivityPub / FEPs / (whatever else there is) do enough to explain how to handle replies, and who gets to moderate them.
So yes, a Reply activity would be a way to do it. However, I don't think it would be enough to just rename the Create activity to Reply. What I would like to see is something along the lines:
- Alice replies to Bob with a Reply activity
- This results in Alice giving/yielding/... Bob the ability to moderate, i.e. delete, the reply
- Furthermore, it will be up to Bob to distribute Alice's reply.
Getting there is complicated! It will probably require some incompatibilities to the current Fediverse. However, I believe it would be worth it.