@mgaruccio I guess it's just having a resilient network that can handle having nodes that are just very occasionally available. Anyways, neat problem to think about.
@surfbum oh good. I want to do what's right for this community and for the internet, and sometimes that means telling well-meaning people they're on the wrong track.
The advice I gave my 17-year-old daughter is this: keep a base here in Montreal, and visit other places as much as you can. Live in them temporarily for months or even years. But keep this place as your home.
My kids both grew up here their entire lives. I feel like that was a big gift we gave them. I hope they know how important it is to keep it, and I hope they never feel stifled by it.
Deciding where you live on this planet is a huge privilege. Most people don't get to choose. The globe isn't a Tinder app they can swipe left and right on.
I'm glad I and my kids have a lot of optionality, but that comes with some pressure to make the right decisions.
This was a good poll. Lots of interesting comments.
I'm a qualified yes. I love my home and my community in Montreal and my second home in Richmond the Eastern Townships, but I'm a settler on indigenous land, and we haven't figured out how that can be a just situation yet.
I'm also far from my parents and brothers in the San Francisco Bay Area, and my extended family in New Jersey.
I think it's an interesting problem. A server running in low-energy mode most of the time would miss any incoming messages.
So you'd need a way to signal to other servers that your low-energy server is back online, and wants to collect any incoming messages.
One way to notify them is by delivering outgoing messages. We should probably make a best practice that if you're doing exponential backoff, and you get an incoming message from the server, it's a good time to retry.
@22 I don't think that's true for gzipped payloads.
I think a low energy implementation of AP would be great. A lot of the fields in AS2 are optional.
I think there are some best practices that could work to make an AP server that is in low-power mode until the client connects, and then delivers outbound activities and solicits delivery of inbound ones.
@risottobias the thundering herd problem, when clients all get the OpenGraph data for a link at once, is a problem with an obvious solution.
We have a rich representation for a link ("Link") in Activity Streams 2.0. Before sending out a post with a link in it, the sending server should do ONE opengraph query, and add the metadata as a link to the outgoing message.
Dying servers is only a problem if you don't use your own domain. We're in an intermediary period; more people and orgs will run their own servers in the future
Scalability isn't a problem reserved for AP. Fanout of messages to thousands of recipients takes time and resources. True in siloed networks as well as federated.
Search is not a technical but a cultural issue in the fediverse.
@22 I'd also say that AP is an extremely extensible protocol. You can build some really cool stuff by making new Activity Streams 2.0 activity and object types.