#social 2019-03-23
2019-03-23 UTC
# 
dansup hows it going cjslep[m] ?
# fr33domlover Has anyone tried plume and writefreely?
# fr33domlover I'm wondering how they compare
# fr33domlover So far plume feels more socially connected, writefreely more like isolated blogs, otoh I guess writefreely is ahead in stability / features?
timbl joined the channel
# trwnh fr33domlover: that's basically correct. writefreely only uses AP for outbox. every incoming activity is pretty much discarded, so no comments, no like notifications, etc
# fr33domlover trwnh, you can't get comments on your blog? :-/
# fr33domlover Hmmm weird, the UI really has no comments
# fr33domlover I've seen this before, but I was sure there was a way to comment
# fr33domlover I mean, isn't that a super basic feature of blogs that aren't plain statis sites?
# fr33domlover will use plume then
# dansup iirc writefreely doesn't support comments or they can be disabled
# trwnh writefreely is an anti-social distraction-free blogging platform. activitypub is only a serialization format, it's not used for anything else except to generate a feed
# trwnh at least, i think they want to do all the feed reader and social stuff in read.as (readfreely?)
# trwnh or read.write.as
# trwnh whatever it's called
xmpp-social joined the channel
# cjslep[m] I think Matt is working on remark.as which is the commenting part of it
# cjslep[m] dansup I'm doing well what about you?
timbl joined the channel
# fr33domlover Sometimes I'm impressed with how sharp some people are with monetizing the stuff they make
# fr33domlover Matt's stuff seems to be free software, which anyone can install, but he still offers support and hosting and it seems there's no lack of ways to make things commercial
# fr33domlover I never think of such things when I write code :P
timbl and timbl_ joined the channel
# fr33domlover jdormit[m] / everyone else, have you found it useful to maintain a cache of the whole comment tree whose context is on another server? Say I'm u@A and I comment on a blog post p@B, when my server A receives my comment, should it care about knowing/fetching the whole comment tree of that remote blog post?
# jdormit[m] I'm storing the object graph locally
# jdormit[m] Like, the whole graph as much as possible. So when I get B's post I traverse its replies and download all the ones I don't already have
# fr33domlover jdormit[m], I'm consdering whether to do that and wondering if I'd gain anything
# jdormit[m] That lets me do arbitrary queries across the whole graph, e.g. search for all the objects that are attributedTo some actor
# jdormit[m] It's a tradeoff between disk space and network traffic, basically
# jdormit[m] But disk space is cheap and being able to query the whole graph locally is super powerful
# cjslep[m] Also a consideration: legality of caching certain content (I think Masto instances in Norway were concerned about certain Japanese content, for example)
# fr33domlover I have 2 potential major uses for caching: (1) when user looks at their outbox, they can see the context of messages etc. (2) when user publishes a comment, they can determine addressing properly
# fr33domlover But in AP, clients are responsible for addressing
# fr33domlover And in AP C2S you only get the outbox as a list of actual activities you created, no context
# fr33domlover Well, you may get replies, but you get those for free via addressing from other servers
# fr33domlover So, I'm unsure if there's an actual need to bother to cache
# jdormit[m] Well, the consideration you should make is whether you are willing to make e.g. 50 network requests to render a thread with 50 replies, vs. just fetching all of those with a single database call. It's going to be orders of magnitude slower if you don't cache remote content, and you'll need to do it asynchronously if you don't want your users waiting ages for the page to load
timbl joined the channel
# fr33domlover jdormit[m], hmmm I'm not sure the situation is that bad: If you GET a comment you made, you'll have all the replies to it cached because other servers addressed you in them. What you won't see is the *ancestors* of your comment. But that's a problem only when the discusion doesn't have a context: If it does, you can simply GET it from its home server and see all the posts. In my case, so far, messages are
# fr33domlover always about something (they're issue comments)
# fr33domlover In Mastodon for example, if there's no context, you don't have an easy way to get all the ancestors on the client side without doing, indeed, many requests
# fr33domlover And Mastodon does cache ancestors iirc and its API lets you get a list of them
# fr33domlover Am I mistaken?
# fr33domlover What I'm saying is, you need only 2 requestss even if ther are 50 comments: 1 request to get your message, 1 request to fetch the context object along with its tree of replies
# fr33domlover cjslep[m] am I making sense? ^_^
# fr33domlover Actually, even if there's no context, you can always set the top-level note as the context
# fr33domlover If you consistently do that, you can always GET the whole tree in 1 request
# jdormit[m] What do you mean by the context object? I thought the context was just a JSON-LD thing that tells you what all the fields mean
# fr33domlover jdormit[m], I mean the 'context' property, not the JSON-LD @context :)
# fr33domlover jdormit[m], for example in a blog system, every comment has a context: the URI of the blog post on which it comments
# jdormit[m] Oh interesting, I didn't know about that
# fr33domlover jdormit[m], if you make sure all comments have a known context, you always know what to GET in order to see the whole conversation ^_^
# jdormit[m] Are there any implementations out there actually setting that?
# fr33domlover jdormit[m], idk actually! I am, but idk if existing ones do
ajordan joined the channel
# fr33domlover As far as I can see, everyone would benefit from setting a context, including Mastodon
# fr33domlover It makes it an O(1) operation to grab the comment tree root
# jdormit[m] does the top-level object actually contain the reply tree? I thought replies were linked via inReplyTo, which links children to parents but not vice-versa
# fr33domlover jdormit[m], there's a replies property. What I plan to do in my C2S code is to take a query parameter that lets you set whether you want a flat list of relies, or the whole tree embedded in a single big JSON object
# fr33domlover That way you can choose whether to get a compact object, or the whole thing so that you can display it to the user
# fr33domlover In 1 request
# fr33domlover s/relies/replies
# jdormit[m] That's smart. I'll start setting context and replies as well, it makes a lot of sense. I don't think you can rely on all federated instances doing the same though...
# fr33domlover jdormit[m], yay this is the first time I'm collaboratively setting properties with another project ^_^ I agree, you can't rely on other instances, but (1) let's ask them to set it if they can (2) either reject stuff that doesn't have context, or (3) do full caching when context is missing, or (4) accept more limited display in such cases / rely on the client to do its best
# fr33domlover jdormit[m], btw it's a client question too: Can on set the context on the client side, POST to my outbox, and my server just keeps it there and later your server can see it?
# fr33domlover Say, in Mastodon, can I set context even if Mastodon itself, say, ignores that property in the processing logic?
# fr33domlover Because as long as it keeps it there, it will be there when you receive my activity, and you can use it
# fr33domlover After I test my code a bit, I'll look into getting context to more places
# fr33domlover ^_^
puck, decentral1se, puckipedia, dmitriz and timbl joined the channel
# cjslep[m] Pleroma sets 'context' for sure, based on previous curl-ing I've done
# jdormit[m] fr33domlover: I don't see a problem with setting context even if certain instances don't read it. Hopefully if enough of the federation standardizes around something that exerts some pressure on the stragglers haha
decentral1se joined the channel