#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 and timbl joined the channel