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 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:
```
set_relationship(&mut self, contact: &str, following: bool, blocking: bool)
friends_is_following(
&mut self,
src_id: &str,
dest_id: &str,
)
friends_is_blocking(
&mut self,
src_id: &str,
dest_id: &str,
)
friends_hops(
&mut self,
opts: FriendsHopsOpts,
)
```
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.
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:
i think in some cases, for peachpub, we will have to be clever with what is there instead of trying to fit everything that is not there into it
@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:
> i think in some cases, for peachpub, we will have to be clever with what is there instead of trying to fit everything that is not there into it
@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
@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
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).
This sounds great to me. I really like your set_relationship function. It's so much clearer to me than friends.follow.
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,
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.
Thanks for explaining.
> 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).
This sounds great to me. I really like your `set_relationship` function. It's so much clearer to me than `friends.follow`.
> 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,
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.
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
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
(you publish a contact message with following: true)
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`)
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.
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.
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.
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.
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 of FriendsHopsOptions and introduces the RelationshipQuerystruct to unite source and dest.
I'm going ahead with the merge 🤘
I've updated this PR to match the friends RPC API in kuska ([PR#21](https://github.com/Kuska-ssb/ssb/pull/21)) which uses `FriendsHops` instead of `FriendsHopsOptions` and introduces the `RelationshipQuery` `struct` to unite `source` and `dest`.
I'm going ahead with the merge 🤘
glyph
merged commit ec348d57ee into sbot-connection2022-02-04 08:31:02 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
glyph
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 finepub 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_relationshipfunction. 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 workingAs far as I can tell by looking at the Go codecase, the
reverseparameter 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
pubbeforefn...) 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
FriendsHopsinstead ofFriendsHopsOptionsand introduces theRelationshipQuerystructto unitesourceanddest.I'm going ahead with the merge 🤘