16:35 <jfred> ocdtrekkie: Agreed on wanting something on sandstorm for the fediverse. That'd take some pretty deep integration though, right?

16:36 <ocdtrekkie> Yes and no. To do it right, yes. To do it badly, not at all.

16:38 <ocdtrekkie> I think you could technically give it IpNetwork, have it KeepAlive, and technically, you might be able to run it? But your fedi name might also be 300 characters long?

16:40 <jonesv> ocdtrekkie: is it the same kind of issues as for Matrix?

16:43 <jfred> I was imagining usernames might look like @jfred@<long id>.sandstorm.terracrypt.net

16:44 <jfred> Conveniently I think Mastodon will try and find users your instance knows about in search given only the local part

16:46 <jfred> Less conveniently it will sometimes show the full name in the UI, and it might count against the character limit for people mentioning you...

20:48 <ocdtrekkie> I'm not sure we have any clear documentation on where all the hangups are for either ActivityPub or Matrix. abliss knows a lot of it though probably.

21:06 <abliss[m]> I knew the hangups for matrix and could probably remember them... i don't think i ever tried activitypub

21:07 <ocdtrekkie> It might be a little easier? I don't know. The DNS/server identity stuff will probably be similarly frustrating.

21:08 <ocdtrekkie> Also, with current events being as they are, the lack of visibility into grain CPU and memory use might be pretty problematic. The fediverse has been murdering servers lately.

21:44 <TimMc> It would probably be fine for single-user instances.

21:59 <jonesv> Are Mastodon servers as inefficient (if I may say it like this 😅) as the Matrix homeservers?

22:04 <jonesv> (I would be curious to compare an IRC server to a Matrix one, someday. And then also to e.g. Mastodon)

22:33 <ocdtrekkie> The big problem is that Mastodon caches a LOT of stuff, everything it sees, basically.

22:57 <jfred> I think you'd probably want something a bit more lightweight than Mastodon anyway, if you're following the Sandstorm pattern of a grain being a small unit within whatever system you're using (probably an AP account per grain would make the most sense IMO)

23:01 <jfred> Epicyon, maybe

23:07 <ocdtrekkie> That would be Sandstorm-y but present some major downsides for ActivityPub

23:08 <ocdtrekkie> Each grain would probably be seen like a different server, wouldn't it? And each grain would be caching all that wonderful federated data.

23:08 <ocdtrekkie> I agree Mastodon is too hefty to make sense though.

23:14 <jfred> It would, but I bet that's often the case anyway (my Sandstorm instance for example is almost entirely single-user) - and for a Sandstorm user, it may be more attractive to create your own grain rather than use someone else's even if they do support multiple users since it's so easy

23:16 <jfred> One big problem that I can see though is that AP inboxes are meant to be long-lived, so e.g. grain backups and restores would not work at all if they resulted in a different randomly-generated endpoint each time one is created

23:17 <jfred> I think you'd need a portable profile type thing like what Spritely has planned for that to make sense

23:19 <ocdtrekkie> I feel like we eventually need a good system for services at well-known endpoints for narrow cases like federation and stuff.

23:21 <ocdtrekkie> Also, like, mail input is handled by Sandstorm and then handed out to grains. I wonder if ActivityPub should be something similar.

23:23 <jfred> Oh, here's a thought: what if, when creating a grain that relied on well-known endpoints, you permanently assigned an ID to that grain in a cryptographically verifiable way - like you include a signed document somewhere in the grain metadata that gets included in a backup. Then if the user restores a backup of that grain, the new grain gets the same ID

23:26 <ocdtrekkie> It'd be the API endpoint that'd need to be consistent, I assume.

23:27 <ocdtrekkie> Restoring webkeys

23:29 <jfred> Right - I'm thinking that ID would be part of the domain for things like federation (which webkeys seem to do now)