@david_megginson the good thing about expectations is that we can adjust them 
I'm not saying replace AP with something else, I'm saying let's build something different and let them all blossom. I really liked the spec described here:
@david_megginson the good thing about expectations is that we can adjust them 
I'm not saying replace AP with something else, I'm saying let's build something different and let them all blossom. I really liked the spec described here:
@julian that was a very interesting read. I think I can implement this. Will try a small experiement soon. Thanks for sharing.
@david_megginson that is the exact problem that I want to get rid of. It really sucks. For example, I'd like to host a single-user AP server here at my flat, but knowing that it will use so much bandwidth is enough for me to reconsider it.
@LovesTha it would be a radically different experience indeed. The key is when to fetch, right? You can’t fetch as you build the feed for visualisation, fetching is slow.
You need to either make it an explicit action such as a refresh button or fetch in the background according to some interval.
Regardless, you would cache it and the feed always shows the cache. It might be out of date but it is local and fast.
Marking broken and inactive accounts is easy.
I wish #ActivityPub was a "pull" protocol instead of a "push" protocol. The way it works, whenever you take an action, it sends that action to all followers. I would prefer if it simply stored them and then let each follower pull them when they see fit.
That would introduce latency and more async comms as your messages wouldn't pop up into someone elses feed until their software fetch the data, but I think it would make it easier to self host.