PeachCloud
/
peach-workspace
3
2
Fork 1
Code Issues 17 Pull Requests Projects Releases Wiki Activity

Domain insertion for invites #127

New Issue
Closed
opened 2022-07-01 08:14:29 +00:00 by glyph · 12 comments
glyph commented 2022-07-01 08:14:29 +00:00
Owner
Copy Link

@notplants

I should have remembered this when reviewing your PR (#125) but the functionality to insert a domain into an invite code already exists in go-ssb and golgi. It is achieved by publishing a pub address message, as documented in the invites section of the golgi developer guide.

@notplants I should have remembered this when reviewing your PR (https://git.coopcloud.tech/PeachCloud/peach-workspace/pulls/125) but the functionality to insert a domain into an invite code already exists in go-ssb and golgi. It is achieved by publishing a `pub address` message, as documented in the invites section of the [golgi developer guide](https://dev.scuttlebutt.nz/#/rust/golgi?id=invites).
notplants commented 2022-07-04 08:11:44 +00:00
Owner
Copy Link

in order to use this method of inserting a domain into the invite,
and to use it during the yunohost install,
I think we would need:

  • to add a golgi function which waits until go-sbot is running (similar to $(document).ready() in jquery)... not sure the best way to do this... perhaps by calling whoami on a poll (with a maximum number of tries before returning an error)... and then returns a successful future once sbot is verified running or the test fails
  • create a peach-config function, peach-config setdomain .... which calls the wait function, and then once go-sbot is ready uses the domain publishing function
  • during yunohost install, after go-sbot has been started, call peach-config setdomain
in order to use this method of inserting a domain into the invite, and to use it during the yunohost install, I think we would need: - to add a golgi function which waits until go-sbot is running (similar to $(document).ready() in jquery)... not sure the best way to do this... perhaps by calling whoami on a poll (with a maximum number of tries before returning an error)... and then returns a successful future once sbot is verified running or the test fails - create a peach-config function, peach-config setdomain .... which calls the wait function, and then once go-sbot is ready uses the domain publishing function - during yunohost install, after go-sbot has been started, call peach-config setdomain <domain>
glyph commented 2022-07-04 08:26:34 +00:00
Author
Owner
Copy Link

Hmmm...I don't fully understand the need for the steps you've described.

The goal as I understand it is to populate the invite code with the external domain name. Is that correct or am I missing something?

Could the value from EXTERNAL_DOMAIN be used to populate a PubAddress message which is then published by the sbot? Generated invite codes would then include the hostname.

Hmmm...I don't fully understand the need for the steps you've described. The goal as I understand it is to populate the invite code with the external domain name. Is that correct or am I missing something? Could the value from `EXTERNAL_DOMAIN` be used to populate a `PubAddress` message which is then published by the sbot? Generated invite codes would then include the hostname.
notplants commented 2022-07-04 08:58:53 +00:00
Owner
Copy Link

Yup that's what I imagine as the goal too

from what I imagine these would be the steps required in order to use the value from EXTERNAL_DOMAIN to populate a PubAddress message which is published by the sbot, like you described

the wait function would be required to wait until the sbot is running, so that the sbot can be used for publishing that message. And the peach-config setdomain function would be required to allow for programmatically calling that golgi function from the command line

or is there another way? this way definitely makes it more complicated to store this state in the go-sbot database, than the current version which just uses config.yml (our own peach state)

we could also make it so that in the the place in the web UI, when you update the external domain, it calls the necessary sbot publish method as well, but from the perspective of yunohost (and also probably other forms of installation) its necessary to be able to set the domain via the CLI, and not just through the web UI

Yup that's what I imagine as the goal too from what I imagine these would be the steps required in order to use the value from EXTERNAL_DOMAIN to populate a PubAddress message which is published by the sbot, like you described the wait function would be required to wait until the sbot is running, so that the sbot can be used for publishing that message. And the peach-config setdomain function would be required to allow for programmatically calling that golgi function from the command line or is there another way? this way definitely makes it more complicated to store this state in the go-sbot database, than the current version which just uses config.yml (our own peach state) we could also make it so that in the the place in the web UI, when you update the external domain, it calls the necessary sbot publish method as well, but from the perspective of yunohost (and also probably other forms of installation) its necessary to be able to set the domain via the CLI, and not just through the web UI
glyph commented 2022-07-04 09:41:30 +00:00
Author
Owner
Copy Link

I think we want a separation of concerns here between PeachCloud / PeachPub and YunoHost.

In terms of PeachCloud, we can add a form field for the external domain and a 'Publish Peach Address' button to the Scuttlebutt Settings page of the UI. We could add explanatory text to describe the connection between the external domain and the generated invite code(s).

I don't understand the need for the wait function. How does YunoHost manage the sbot process? Does it use systemd? If so, could you query the status of the process before using golgi to publish the pub address message?

I'm not familiar with the YunoHost application installation process so I might be missing some context here.

I think we want a separation of concerns here between PeachCloud / PeachPub and YunoHost. In terms of PeachCloud, we can add a form field for the external domain and a 'Publish Peach Address' button to the Scuttlebutt Settings page of the UI. We could add explanatory text to describe the connection between the external domain and the generated invite code(s). I don't understand the need for the `wait` function. How does YunoHost manage the sbot process? Does it use `systemd`? If so, could you query the status of the process before using golgi to publish the pub address message? I'm not familiar with the YunoHost application installation process so I might be missing some context here.
notplants commented 2022-07-04 10:35:14 +00:00
Owner
Copy Link

Does it use systemd? If so, could you query the status of the process before using golgi to publish the pub address message?

Yup it uses systemd. I see what you describe as an implementation of a .ready function outside of golgi. If a .ready function were implemented within golgi, it could be used by any golgi user who wants to ensure the sbot is running before whatever they need to do. I would see the question of whether that should live inside of or outside of golgi as a question of whether such a utility would also be useful to other users. Its interesting that currently with golgi, its my understanding that if you create an sbot_client, it will succeed even if the sbot isn't necessarily running, in part because we make a new connection for each request.

I'm not familiar with the YunoHost application installation process so I might be missing some context here.

Its just about timing, that you need to wait until the service is running, in order to use it. This could be implemented outside of golgi, but it also seems like an issue that many golgi users might encounter (is sbot running, before I issue my command).

In terms of PeachCloud, we can add a form field for the external domain and a 'Publish Peach Address' button to the Scuttlebutt Settings page of the UI. We could add explanatory text to describe the connection between the external domain and the generated invite code(s).

fwiw there is a form field for external domain within the dynamic dns configuration (which is not displayed in peachpub mode). I guess when you save a new value it could in the background publish the address, or "Publish Peach Address" could be its own button, I'm not sure which is more intuitive. From my reading (https://handbook.scuttlebutt.nz/guides/pubs/announce-a-pub-server), publishing your address is also about peers discovering the address of the pub, not just inserting it into invites.

Based on this conversation, my understanding of steps forward would be:

  • implement the .ready function outside of golgi, using bash commands in the yunohost installation
  • add a peach-config setdomain method which calls the golgi command, so it can be used from the command line
  • call this command during the yunohost install

It also seems reasonable that the .ready function is outside of the peach-config setdomain function too, which maybe should just return a failure if for some reason sbot is not running, instead of waiting for sbot to run.

> Does it use `systemd`? If so, could you query the status of the process before using golgi to publish the pub address message? Yup it uses systemd. I see what you describe as an implementation of a .ready function outside of golgi. If a .ready function were implemented within golgi, it could be used by any golgi user who wants to ensure the sbot is running before whatever they need to do. I would see the question of whether that should live inside of or outside of golgi as a question of whether such a utility would also be useful to other users. Its interesting that currently with golgi, its my understanding that if you create an sbot_client, it will succeed even if the sbot isn't necessarily running, in part because we make a new connection for each request. > I'm not familiar with the YunoHost application installation process so I might be missing some context here. Its just about timing, that you need to wait until the service is running, in order to use it. This could be implemented outside of golgi, but it also seems like an issue that many golgi users might encounter (is sbot running, before I issue my command). > In terms of PeachCloud, we can add a form field for the external domain and a 'Publish Peach Address' button to the Scuttlebutt Settings page of the UI. We could add explanatory text to describe the connection between the external domain and the generated invite code(s). fwiw there is a form field for external domain within the dynamic dns configuration (which is not displayed in peachpub mode). I guess when you save a new value it could in the background publish the address, or "Publish Peach Address" could be its own button, I'm not sure which is more intuitive. From my reading (https://handbook.scuttlebutt.nz/guides/pubs/announce-a-pub-server), publishing your address is also about peers discovering the address of the pub, not just inserting it into invites. Based on this conversation, my understanding of steps forward would be: - implement the .ready function outside of golgi, using bash commands in the yunohost installation - add a peach-config setdomain method which calls the golgi command, so it can be used from the command line - call this command during the yunohost install It also seems reasonable that the .ready function is outside of the peach-config setdomain function too, which maybe should just return a failure if for some reason sbot is not running, instead of waiting for sbot to run.
glyph commented 2022-07-05 07:55:53 +00:00
Author
Owner
Copy Link

I would see the question of whether that should live inside of or outside of golgi as a question of whether such a utility would also be useful to other users.

That's interesting. I think my general philosophy is to keep golgi as lean as possible and not fall into the "batteries included" trap. Whether a process is running or not seems like a process manager / operating system concern to me.

Do you know about SbotStat and sbot_stats() in peach-stats? That gives a neat way to query the state of the go-sbot process: https://git.coopcloud.tech/PeachCloud/peach-workspace/src/branch/main/peach-stats/src/sbot.rs. I will just need to update the systemctl commands since we are no longer running go-sbot as a user process (made an issue here: #129).

fwiw there is a form field for external domain within the dynamic dns configuration (which is not displayed in peachpub mode). I guess when you save a new value it could in the background publish the address, or "Publish Peach Address" could be its own button, I'm not sure which is more intuitive.

We can get a sense of which way will be best when I start reintegrating the complete PeachCloud mode.

From my reading [..], publishing your address is also about peers discovering the address of the pub, not just inserting it into invites.

👍 👍

It also seems reasonable that the .ready function is outside of the peach-config setdomain function too, which maybe should just return a failure if for some reason sbot is not running, instead of waiting for sbot to run.

That's the way I would do it; separating the 'what' from the 'when'.

> I would see the question of whether that should live inside of or outside of golgi as a question of whether such a utility would also be useful to other users. That's interesting. I think my general philosophy is to keep golgi as lean as possible and not fall into the "batteries included" trap. Whether a process is running or not seems like a process manager / operating system concern to me. Do you know about `SbotStat` and `sbot_stats()` in `peach-stats`? That gives a neat way to query the state of the go-sbot process: https://git.coopcloud.tech/PeachCloud/peach-workspace/src/branch/main/peach-stats/src/sbot.rs. I will just need to update the `systemctl` commands since we are no longer running `go-sbot` as a user process (made an issue here: https://git.coopcloud.tech/PeachCloud/peach-workspace/issues/129). > fwiw there is a form field for external domain within the dynamic dns configuration (which is not displayed in peachpub mode). I guess when you save a new value it could in the background publish the address, or "Publish Peach Address" could be its own button, I'm not sure which is more intuitive. We can get a sense of which way will be best when I start reintegrating the complete PeachCloud mode. > From my reading [..], publishing your address is also about peers discovering the address of the pub, not just inserting it into invites. 👍 👍 > It also seems reasonable that the .ready function is outside of the peach-config setdomain function too, which maybe should just return a failure if for some reason sbot is not running, instead of waiting for sbot to run. That's the way I would do it; separating the 'what' from the 'when'.
notplants commented 2022-07-05 12:43:41 +00:00
Owner
Copy Link

That's interesting. I think my general philosophy is to keep golgi as lean as possible and not fall into the "batteries included" trap. Whether a process is running or not seems like a process manager / operating system concern to me.

I could see excluding it too. I guess for determining what's in and outside of a library, I might be pragmatically oriented, that if I need something for some usecase, I imagine its more likely someone else might want it to. Building things that are only theoretically useful is where I'd be more conservative.

We can get a sense of which way will be best when I start reintegrating the complete PeachCloud mode.

👍

That's the way I would do it; separating the 'what' from the 'when'.

👍

> That's interesting. I think my general philosophy is to keep golgi as lean as possible and not fall into the "batteries included" trap. Whether a process is running or not seems like a process manager / operating system concern to me. I could see excluding it too. I guess for determining what's in and outside of a library, I might be pragmatically oriented, that if I need something for some usecase, I imagine its more likely someone else might want it to. Building things that are only theoretically useful is where I'd be more conservative. > We can get a sense of which way will be best when I start reintegrating the complete PeachCloud mode. 👍 > That's the way I would do it; separating the 'what' from the 'when'. 👍
glyph commented 2022-07-05 13:02:01 +00:00
Author
Owner
Copy Link

I can understand your desire to take a pragmatic approach. We're in an interesting position where development on PeachCloud and golgi are happening at the same time, with the same development team. There's a chance in those situations that functionality gets added to the standalone library when it should rather be in the application which is relying on the library. That's the situation I'm trying to avoid.

Other people who end up using golgi might use it in totally different contexts to us. If several users end up requesting a feature that we've implemented outside of golgi then we can always add it in (it's easier to add than to take away).

I can understand your desire to take a pragmatic approach. We're in an interesting position where development on PeachCloud and golgi are happening at the same time, with the same development team. There's a chance in those situations that functionality gets added to the standalone library when it should rather be in the application which is relying on the library. That's the situation I'm trying to avoid. Other people who end up using golgi might use it in totally different contexts to us. If several users end up requesting a feature that we've implemented outside of golgi then we can always add it in (it's easier to add than to take away).
👍 1
notplants commented 2022-07-11 15:45:32 +00:00
Owner
Copy Link

@glyph I'm having quite a hard time getting the .ready() function to work properly in bash, mostly because bash has some limitations and is difficult for me to work with.

based on what you said, if not in golgi, would you support me implementing the sbot.ready() function in peach-config?

peach-config wait-for-sbot

... returns true once sbot is ready and whoami is successful... and returns an error if sbot doesn't return successfully after some numer of attempts

@glyph I'm having quite a hard time getting the .ready() function to work properly in bash, mostly because bash has some limitations and is difficult for me to work with. based on what you said, if not in golgi, would you support me implementing the sbot.ready() function in peach-config? peach-config wait-for-sbot ... returns true once sbot is ready and whoami is successful... and returns an error if sbot doesn't return successfully after some numer of attempts
glyph commented 2022-07-12 06:57:09 +00:00
Author
Owner
Copy Link

@notplants

based on what you said, if not in golgi, would you support me implementing the sbot.ready() function in peach-config?

Yup, I'm happy with that option.

@notplants > based on what you said, if not in golgi, would you support me implementing the sbot.ready() function in peach-config? Yup, I'm happy with that option.
👍 1
notplants commented 2022-07-27 09:22:16 +00:00
Owner
Copy Link

I knew at some level this was non-trivial, because it required working with the sbot during yunohost commands, which was not previously needed before, ended up being a big project, but 3 weeks later it is now merged in #131, and the yunohost package is all green again.

I'm going to wait until the quality of the yunohost pacakage is updated to "good quality" in the yunohost application catalog,
before sharing more broadly (I think there is just a lag in reflecting this in the catalog, and I'm not sure why its currently marked as "low quality").

I believe the updates to the yunohost catalog happen on Fridays.

I knew at some level this was non-trivial, because it required working with the sbot during yunohost commands, which was not previously needed before, ended up being a big project, but 3 weeks later it is now merged in https://git.coopcloud.tech/PeachCloud/peach-workspace/pulls/131, and the yunohost package is all green again. I'm going to wait until the quality of the yunohost pacakage is updated to "good quality" in the yunohost application catalog, before sharing more broadly (I think there is just a lag in reflecting this in the catalog, and I'm not sure why its currently marked as "low quality"). I believe the updates to the yunohost catalog happen on Fridays.
notplants commented 2022-07-27 09:33:11 +00:00
Owner
Copy Link

and the relevant PR in the yunohost package https://github.com/YunoHost-Apps/peachpub_ynh/pull/13

and the relevant PR in the yunohost package https://github.com/YunoHost-Apps/peachpub_ynh/pull/13
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
main
supervisorctl
update_wpactrl_api
fix_clippy_warning
ssb_status_design
fix-regression
forget_update_network
network_rpc_server
refactor_network_error
lib_error_refactor
Labels
Clear labels
  
bug

Something is not working

  
documentation

   
duplicate

This issue or pull request already exists

  
enhancement

New feature

  
help wanted

Need some help

  
invalid

Something is wrong

  
maintenance

Pruning and weeding

  
peach-lib

   
peach-network

   
peach-oled

   
peach-stats

   
peach-web

   
question

More information is needed

  
refactor

Code rewrite

  
wontfix

This won't be fixed

No Label
bug
documentation
duplicate
enhancement
help wanted
invalid
maintenance
peach-lib
peach-network
peach-oled
peach-stats
peach-web
question
refactor
wontfix
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: PeachCloud/peach-workspace#127
No description provided.
Delete Branch "%!s(<nil>)"

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?