Add methods for following, blocking and looking up peers #18
Loading…
Reference in New Issue
No description provided.
Delete Branch "friends-requests"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I added an example examples/ssb-friends.rs which probably shows the state of things best.
The strangest bug I found, is that go-sbot friends hops is not finding the most recent contact message... but it finds all contact messages before that just fine.
This bug is seen for both friends hops, as well as friends isFollowing and friends isBlocking.
This means the first time you run the ssb-friends example it will return the incorrect values. But if you re-run it, every time after that it will return the correct values.
Here are the relevant functions that were added which make muxrpc calls:
The other functions added are syntactic sugar on top of these functions.
One other important possible bug I found in go-sbot. friends hops does not seem to take into account the reverse parameter (documented here https://github.com/ssbc/ssb-friends) which is used to get your followers instead of your follows. Currently friends hops returns your follows regardless what you pass here, and I haven't thought of any way to get your followers.
I wrote all of these different functions at once, so we could see the whole state of the friends API and find if there are any workarounds. I believe if we fixed those two bugs mentioned above in go-sbot, then we could get all the info we need for PeachPub.
I also listed a couple other possible issues I found in this doc (https://server.commoninternet.net/pad/p/sbot_issues) but I don't think they are blocking issues.
Here is a PR with the additions to kuska that make this golgi code functional:
https://github.com/mhfowler/kuska-ssb/pull/1
Also added a git hook for cargo fmt, which I'm now using, and hopefully reduces whitespace clutter
@notplants
I've made a couple of comments. There are some things we need to consider before merging, I think.
I also agree with the comment @cblgh made on cabal:
@ -183,0 +215,4 @@
/// if state is false, then sets the following status to false (unfollow)
/// TODO: currently this method is not working (seems to be missing from go-sbot)
/// as a workaround, we can use set_relationship instead just fine
pub async fn friends_follow(
I'm a bit puzzled by the utility of this method. Could you help me understand? Why not just have two functions:
follow()
andunfollow()
?@glyph friends.follow is one of the muxrpc methods defined in https://github.com/ssbc/ssb-friends. I thought we could definite it here in the same way so there is some symmetry between the golgi api and the js side.
It seems that friends.follow is not currently implemented in go-sbot anyway,
so I would actually just remove this function for now anyway,
and use the set_relationsip function I wrote above (and we can also write follow and unfollow methods that call set_relationship).
In the future, in an ideal world, I think it could be a good idea for golgi to intentionally implement all of the muxrpc methods as part of its API, in the same way as they are in javascript, to make documentation clear and uniform, between both stacks,
even if golgi also then implements additional convenience methods that do things in other ways. But since go-sbot doesnt seem to yet implement all the same muxrpc calls as the js side, then this interface symmetry is not achievable for now anyway
Thanks for explaining.
This sounds great to me. I really like your
set_relationship
function. It's so much clearer to me thanfriends.follow
.I'd love to discuss this in detail another time because I think it's a very important design decision. My brief opinion is that there are some ugly parts of the JS API that I really don't want to emulate just to achieve a 1:1 mapping. I'd rather have a beautiful, clear and consistent golgi API that deviated from JS in places.
One option might be to ask arj, staltz and mix for their opinion ("which of these methods are necessary in your opinion and which are best left out?"), since they're the ones with the most experience of the JS stack.
hmm interesting, could see either way ~
I guess its mostly a question of exclusion
A - I could imagine a muxrpc file in golgi which simply includes a 1:1 golgi function for each muxrpc function,
even if most rust applications on top of golgi dont actually use all those calls
B - could intentionally leave out functions like friends.follow which we decide golgi doesn't want to support
re friends.follow not existing, just for reference: here's how sbotcli handles it: https://github.com/cryptoscope/ssb/blob/master/cmd/sbotcli/publish.go#L229
(you publish a contact message with
following: true
)@ -183,0 +286,4 @@
}
// Gets a Vec<String> where each element is a peer who follows you
/// TODO: currently this method is not working
As far as I can tell by looking at the Go codecase, the
reverse
parameter is not supported for this RPC call. I think it might be best to keep such calls out of the public API of golgi to avoid any confusion, at least until some future time when either A) we learn that the parameter is actually supported but not working for some reason, or B) parameter support is added.that sounds like a good plan - in this PR I was mostly just trying to document everything I tried so we could see the state of what's missing.
the missing reverse parameter is a particularly big missing feature, since I'm not sure how we can look up someone's followers without it.
Maybe I could modify this function to return an empty list for now,
with a todo next to it,
and then we could still call this function in the PeachPub UI for the routes that need it, knowing that eventually it will be implemented,
but for now it cannot be due to a limitation of go-sbot.
Could also remove the function entirely, but it does seem like this is pretty much the function we would want, at some point.
Oh yeah I just meant keeping it out of the public API (no
pub
beforefn...
) so that it's still all there but not available to a library user.hmm since we actually will want to use this function to write the Peers route in peach-web, we would need it to be pub for that. But for now I'll removed the pub.
I've updated this PR to match the friends RPC API in kuska (PR#21) which uses
FriendsHops
instead ofFriendsHopsOptions
and introduces theRelationshipQuery
struct
to unitesource
anddest
.I'm going ahead with the merge 🤘