Thread between @mix, @Piet and me forking to public.
@Hendrik Peter writes
I really love the stuff you (and others in the #sunrisechoir) put together!
Some thoughts from my side after playing with the API’s:
I noticed I’m only getting 10 messages at a time, It’s a nice number that I can probably paginate with, but it would be nice to bump that a bit to say 20-30. the chances of 10 items all being visible in 1 interface view are quite big (triggering instant pagination).
Are likes { } limited in some way? if so, I’ll probably go with x, y, z and [likeCount - 3] others. In other ssb related interfaces & services likes are often revered to as votes, was there a reason to differ from the standard?
I love the “posts” and “public” (aka “public” & “extended network” in Patchwork) lists. I suspect that everyone trying to build apps will at some point try to get these lists working. Would it be possible to pre-cache this data and make it a posts(last: 100, orderBy: ASSERTED, template: PUBLIC) template?
Far away future thingy
The target of my Hub will be to (maybe slightly against ssb’s credo) run from a “server”, is it possible to assert tokens in the graphQL query headers for increased security?
Small OSX bug:
ssb-patchql doesn’t quit when patchbay & the ssb-server behind patchbay do. I need to open my process-monitor and FC them manually. this may be on my side as I do see
function stop () {
if (childProcess) {
childProcess.kill()
}
}
@mix replies
’m not in sunrise choir but I can take a stab at answering some of these:
Are likes { } limited in some way? if so, I’ll probably go with x, y, z and [likeCount - 3] others.
I didn’t quite understand this question or that follow up bit. Can you explain more.
likes are often revered to as votes, was there a reason to differ from the standard
I would “guess” that the average consumer of this doesn’t need to know about the background message types too closely. Likes is a lot more accessible. There are a few legacy weird naming things in scuttlebutt. It’s really difficult knowing when others need burdening with those details or when we can just make things easier. IMO this feels like a clear and safe win.
Would it be possible to pre-cache this data and make it a posts(last: 100, orderBy: ASSERTED, template: PUBLIC) template?
Yes, everything is possible! At the moment as I understand it, the sunrise-choir are working to get a minimal set to production. This work here is the culmination of 6 months. So more features will likely come (or can be added), and, probably not until we’ve figured out how to build installers, documented everything that’s already there really well, started using some of what’s already been made in e.g. patchbay to see what it’s like, gathered lots of feedback from people like you to see what’s hurting most and needs love.
@mix continues
Closing the rust server needs to be done by hooking server.close e.g. https://github.com/ssbc/ssb-suggest/blob/master/index.js#L24-L27
so something like:
server.close.hook(function (fn, args) {
// a command that closes the graphql server
return fn.apply(this, args)
})
Here you go ! https://github.com/sunrise-choir/jsbot-patchql/pull/4
@piet replies
I noticed I’m only getting 10 messages at a time
There must be a bug with the number of results getting returned. That has been working fine but I changed some things very recently that must have broken it. Or, it might be your query, so can you show me the query you’re using?
often revered to as votes, was there a reason to differ from the standard?
Not really, I chose a name that would be most familiar to someone coming from outside. Likes are straight outta facebook. And also that’s the naming that’s used all through the patchwork code.
I suspect that everyone trying to build apps will at some point try to get these lists working. Would it be possible to pre-cache this data and make it a posts(last: 100, orderBy: ASSERTED, template: PUBLIC) template?
As @mixmix says, anything is possible.
I’m actually leaning towards not doing this. My preference is to not opinionate this api too early. I’d much rather have a bunch of example queries that you can copy paste. Like, “here’s a query to build a public feed like patchwork”.
@mix chips in
Or, it might be your query, so can you show me the query you’re using?
@Hendrik Peter let’s fork our learning into the open. That way people can see it’s ok to ask, and they can learn graphql at the same time. Can you re-ask the question in public in #ssb-patchql or #ssb-learning and include your query?
I’m actually leaning towards not doing this. My preference is to not opinionate this api too early. I’d much rather have a bunch of example queries that you can copy paste. Like, “here’s a query to build a public feed like patchwork”.
Heck yes, I agree with this !