Explore names RPC methods #35

New Issue

glyph · 2022-03-02T12:06:15Z

glyph commented

2022-03-02 12:06:15 +00:00

Go-SSB supports three name / image-related methods:

a781ad4ee5/sbot/manifest.go (L89)

"names": {
    "get": "async",
    "getImageFor": "async",
    "getSignifier": "async"
},

According to ssb-names, they do the following:

get() : get all naming relationships
getImageFor(id) : get the image for an id
getSignifier(id) : get the name for an id. returns a name for this id.

This could be a great way to simplify some of the about API methods in golgi.

Go-SSB supports three name / image-related methods: https://github.com/cryptoscope/ssb/blob/a781ad4ee51523df1d3858d9859c285d0eeb2fb1/sbot/manifest.go#L89 ``` "names": { "get": "async", "getImageFor": "async", "getSignifier": "async" }, ``` According to [ssb-names](https://github.com/ssbc/ssb-names), they do the following: get() : get all naming relationships getImageFor(id) : get the image for an id getSignifier(id) : get the name for an id. returns a name for this id. This could be a great way to simplify some of the `about` API methods in golgi.

glyph added the

enhancement

label 2022-03-02 12:06:20 +00:00

glyph referenced this issue

2022-03-27 10:00:19 +00:00

2022 Roadmap #37

glyph commented

2022-05-18 11:57:28 +00:00

@notplants

Today I've been taking a look at this and experimenting with kuska.

The methods themselves are really efficient when interacting with a go-sbot. name.getSignifier(ssb_id) returns the latest name as a string and simply returns the ID if a name is not found in the local sbot log. I don't have any benchmarks for comparison but I think this will be quite a lot quicker than our current stream filtering approach. It'll make a big difference on the follows / followers / friends views in PeachCloud where we need to look-up names for many peers at once.

Now the not-so-great news: I've learned that these methods are not implemented in Patchwork and Manyverse. Patchwork uses ssb-about, and Manyverse uses aboutSelf (from ssb-db2).

Since our current about methods use getSubset queries under the hood, they will also not work with Patchwork.

So we have an interesting decision to make. One idea is to continue on our original path of focusing golgi development on go-ssb interoperability. This will lead to the best outcomes for PeachCloud and might prevent us tying ourselves in knots trying to cover all the bases (Go-SSB, Patchwork, Manyverse etc.).

For example, I could refactor our get_name() method to use names.getSignifier and leave get_latest_about_message() as it currently is. Then, when using go-ssb, one can use get_name() for the most efficient result but could instead use get_latest_about_message() if communicating with another client which has getSubset but not support for ssb-names.

@notplants Today I've been taking a look at this and experimenting with kuska. The methods themselves are really efficient when interacting with a go-sbot. `name.getSignifier(ssb_id)` returns the latest name as a string and simply returns the ID if a name is not found in the local sbot log. I don't have any benchmarks for comparison but I think this will be quite a lot quicker than our current stream filtering approach. It'll make a big difference on the follows / followers / friends views in PeachCloud where we need to look-up names for many peers at once. Now the not-so-great news: I've learned that these methods are not implemented in Patchwork and Manyverse. Patchwork uses [ssb-about](https://github.com/ssbc/patchwork/blob/55fc93a9190c25f467ead205ab8d676b5191dbd4/lib/server-process.js#L19-L25), and Manyverse uses [aboutSelf](https://gitlab.com/staltz/manyverse/-/blob/a18ab66e548946a1d610b3d0e0f331781ccdd8cb/src/backend/plugins/aboutSelf.ts) (from ssb-db2). Since our current `about` methods use `getSubset` queries under the hood, they will also not work with Patchwork. So we have an interesting decision to make. One idea is to continue on our original path of focusing golgi development on go-ssb interoperability. This will lead to the best outcomes for PeachCloud and might prevent us tying ourselves in knots trying to cover all the bases (Go-SSB, Patchwork, Manyverse etc.). For example, I could refactor our `get_name()` method to use `names.getSignifier` and leave `get_latest_about_message()` as it currently is. Then, when using go-ssb, one can use `get_name()` for the most efficient result but could instead use `get_latest_about_message()` if communicating with another client which has `getSubset` but not support for `ssb-names`.

notplants commented

2022-05-18 14:48:51 +00:00

that all sounds good to me. I would be a bit surprised if filtering in rust for names from about messages was a major bottleneck given that there is probably a pretty small number of about messages that any user has, but as you mentioned, since there could be a large list to get names for, a small difference could be multiplied, so sounds worth exploring

in regards to supporting different servers and their interfaces, there was also a related discussion at one point about whether to keep the muxrpc functions for the sake of it, or just have new ones that made more sense

I would lean towards providing the underlying functions where possible in a 1:1 mapping, in addition to any of our functions that we define,
so that if there is a particular function you want to call (e.g. names.getSignifier), you can call it, and the function ideally has the same name in golgi so its easy to find. I could see this being helpful for people using golgi with various servers with various subsets of muxrpc implemented, and that if they know what functions their server implements, they can only use those functions from golgi. I'm not sure if there is some sane way to indicate which functions are directly mapped to muxrpc functions, and which are our own, or are composite functions on top of the muxrpc stuff. but indeed, it seems like a red herring to try to focus on supporting all servers, especially initially, so maybe lets just prioritize go-sbot integration. what you described with names and get_about_messages makes sense to me

that all sounds good to me. I would be a bit surprised if filtering in rust for names from about messages was a major bottleneck given that there is probably a pretty small number of about messages that any user has, but as you mentioned, since there could be a large list to get names for, a small difference could be multiplied, so sounds worth exploring in regards to supporting different servers and their interfaces, there was also a related discussion at one point about whether to keep the muxrpc functions for the sake of it, or just have new ones that made more sense I would lean towards providing the underlying functions where possible in a 1:1 mapping, in addition to any of our functions that we define, so that if there is a particular function you want to call (e.g. names.getSignifier), you can call it, and the function ideally has the same name in golgi so its easy to find. I could see this being helpful for people using golgi with various servers with various subsets of muxrpc implemented, and that if they know what functions their server implements, they can only use those functions from golgi. I'm not sure if there is some sane way to indicate which functions are directly mapped to muxrpc functions, and which are our own, or are composite functions on top of the muxrpc stuff. but indeed, it seems like a red herring to try to focus on supporting all servers, especially initially, so maybe lets just prioritize go-sbot integration. what you described with names and get_about_messages makes sense to me

👍 1

glyph commented

2022-07-11 10:49:02 +00:00

@notplants

Thanks for your thoughts and a sanity check on this. I'm revisiting this work this week and it was really helpful to reread this discussion.

I would lean towards providing the underlying functions where possible in a 1:1 mapping, in addition to any of our functions that we define

Cool, this sounds good to me.

I'm not sure if there is some sane way to indicate which functions are directly mapped to muxrpc functions, and which are our own, or are composite functions on top of the muxrpc stuff.

That's an interesting idea. I like it. I'll give this some thought while I work. One option is to add some sort of tag or keyword to the doc comments of each function.

@notplants Thanks for your thoughts and a sanity check on this. I'm revisiting this work this week and it was really helpful to reread this discussion. > I would lean towards providing the underlying functions where possible in a 1:1 mapping, in addition to any of our functions that we define Cool, this sounds good to me. > I'm not sure if there is some sane way to indicate which functions are directly mapped to muxrpc functions, and which are our own, or are composite functions on top of the muxrpc stuff. That's an interesting idea. I like it. I'll give this some thought while I work. One option is to add some sort of tag or keyword to the doc comments of each function.

glyph commented

2022-08-07 12:13:20 +00:00

The three methods mentioned above have now been merged into kuska:

https://github.com/Kuska-ssb/ssb/pull/27

The three methods mentioned above have now been merged into kuska: https://github.com/Kuska-ssb/ssb/pull/27

glyph commented

2022-11-22 12:14:09 +00:00

Merged in #53

Merged in https://git.coopcloud.tech/golgi-ssb/golgi/pulls/53

glyph closed this issue

2022-11-22 12:14:13 +00:00

Sign in to join this conversation.