#social 2019-04-26
2019-04-26 UTC
# 
jdormit[m] I was talking with fr33domlover the other day on here about whether or not to keep local copies of all incoming activities. I was pretty convinced that you should in order to be able to query the whole graph and to save network bandwidth, but I've been doing a lot of reading about RDF/linked data and I'm getting less convinced
# jdormit[m] How do people here handle that? Do you persistent a local copy of incoming activities, or do you just dereference IRIs whenever you need to access a foreign node in the object graph?
# jdormit[m] My thinking these days is that the best approach is to only persist to disk the data that you own, but keep a cache of all objects that you see so you save network requests and disk space
# rialtate[m] I think it depends on what type of experience an impl wants to provide. Both approaches are valid.
# rialtate[m] For most of our projects at allied we persist all objects. For various reasons™
# fr33domlover jdormit[m], I guess it depends on the implementation too: I keep a local cache of some stuff, but only very specific stuff, not everything. Right now in my implementation the only federated thing is Create Note, and if the root of a conversation tree is local to my server, then I keep copies of remotely authored messages, so that the conversation log remains even if servers go down
# fr33domlover But otherwise I don't just default to keeping everything, I keep stuff if I see how it's going to be used
# fr33domlover It also helps me track db space usage
# fr33domlover By storing stuff that I know why I store
# rialtate[m] One real big reason to store them is if your db format doesn't resemble json-ld in any way. It would be bad times to try to decompose a whole conversation on the fly.
# fr33domlover rialtate[m], yeah and that's assuming it's required on the server side; often it's just on the client and then it's a much smaller issue (you can paginate / dynamically load posts anyway, which server they come from makes little difference)
# fr33domlover So I guess it depends a lot on the specific software and its needs
# dansup jdormit[m]: pixelfed normalizes some objects, storing the whole object is not required if you have a strong schema IMO
# jdormit[m] Haha, the classic "it depends". For my purposes, since I'm targeting self-hosted WordPress, I think it makes sense to keep the DB small but to cache what I can
# jdormit[m] dansup: yeah, reading up on JSON-LD and rdf schemas is what changed my thinking
# fr33domlover jdormit[m], btw note that caching doesn't always make much difference to bandwidth: If you need a client to see some 100 comments on a post, or some 100 posts or whatever, it doesn't necessarily matter from which server(s) they're downloaded
# dansup jdormit[m]: I guess it depends on the scope of the project. Only accepting 1 actor type and a few activity types means pixelfed can treat AP in its own terms instead of building around AP
# fr33domlover I currently have a static UI so caching makes this sort of thing much easier for me; but given a dynamic one, idk if I'd need caching as much
# fr33domlover Maybe I wouldn't cache
# dansup fr33domlover: which project are you working on again? it's forgefed right?
# fr33domlover dansup, yes. it will have more than just Create Note, but I'm currently implementing the core AP stuff and just Create Note, so that I have all the basics working before I do less common things ^_^
# dansup fr33domlover: still need some UI help? https://i.dansup.xyz/a2cf4443c4e7 :)
# fr33domlover dansup, yeah it would be cool to reuse what you made :) but too early for actual integration, I guess I need the API etc. to properly exist
# dansup fr33domlover: Can't wait to help! ForgeFed will have a slick UI :D
# fr33domlover dansup :) btw it's very possible that my implementation will end up being more like a demo, and the more important implementation work will be to bring federation to GitLab, Gitea etc.
# fr33domlover I wonder how that part is going to go
# fr33domlover The only part I'm sure about it Vervis, my implementation
# fr33domlover :P
# fr33domlover dansup, slick UI would be great ^_^ hopefully helps attract people to it, to give ForgeFed a try
# dansup I think ForgeFed will be a great Gitea/GitLab alternative
# dansup Atleast they are considering it, I doubt Instagram will ever support ActivityPub lol
# fr33domlover Well technically Gitab has had issues about it since 2015-2016
# fr33domlover And not a single line of code written
# fr33domlover I wonder if they really even want that stuff there
# fr33domlover Considering their paying customers probably don't need or want federation
# dansup probably not, they have VC funding and need to make profit
# fr33domlover Or extra ways for their proprietary stuff to accidentally be seen
# dansup At least we know Microsoft somewhat embraces open source, doubt GitHub would ever implement AP but better than Oracle acquiring GitLab and pulling AP support if ever implemented.
# fr33domlover dansup, I actually wonder if githu8's profits would be affected much by implementing AP; I guess its paying customers may still be used to its UI, and whatever "enterprise" features it has etc.
# fr33domlover On the other hand, AP would be a bridge for many of the non-paying users to leave to other servers
# fr33domlover Which I suppose could decrease their monopoly
# fr33domlover Actually I hope that happens either way lol
# fr33domlover (Or they make all their code free, that's okay too)
# fr33domlover (And then we can have many githu8 servers in the wild!)
# dansup heh
# dansup I'm a happy GitHub customer even after they made private repos free. I would never run my own instance because it would not be as reliable
# dansup thats just git hosting, its decentralized and I can use any other service at will
# dansup git is decentralized I mean
# rialtate[m] Federation is beneficial to any business plan that *isn't* "try to be monopoly"
# fr33domlover Well githu8 probably benefits a lot from being a monopoly
# fr33domlover Tons of projects are there for the visibility
# fr33domlover If everyone would freely migrate to other servers while keeping the visibility due to federation, I guess that could change the picture a lot
# fr33domlover I'm very curious to see how it turns out
# fr33domlover (how, sorry for pinging you; your nickname happens to be a common english word!)
vitalyster, xmpp-social, timbl, bigbluehat, englishm_, cwebber2, brion, vasilakisfil, englishm and how joined the channel