You are reading content from Scuttlebutt
@Daan %ZmVU6fAkAJvFxxM7zH1cw/zYwpHZlcsyudTOcNtqyXg=.sha256

I'm having some trouble with #go-ssb at the moment. Or with #golgi / #kuska, not sure really. Very likely this is just me "holding it wrong" but I've been stuck here for a few (entertaining) hours and I don't see how to make progress with this.

As I said earlier I'm following the #lykin tutorial series and I'm currently in part 3 where there's actual following/unfollowing happening.

The problem I'm seeing

The following state between what sbotcli hist and what golgi give me becomes out of sync.

There's a lot going on in that video and I made it brief to stay under the 5MB blob limit. Let's unpack this:

  1. I start go-sbot from terminal to see it's up in the bottom left terminal.
  2. I query the latest two posts made by my id in the bottom right terminal.
    They show up in reverse chronological order (I couldn't find a way to query only the last two items in chronological order... /cc @cryptix?)
    We can see that the last message published was number 21 which set the follow state to boolean true for @MRiJ+Cv... (yours truly).
  3. I check the follow status in lykin. This is a new route I added to be able to see the go-sbot state through the filter of golgi and rocket, like the other forms built in the lykin series. And indeed we see that the hist and the golgi states agree on "true" (a string) being the status.
  4. I hit Unsubscribe in the lykin interface. In the top-left terminal we see the logs from rocket & lykin appear, confirming that the unfollow action happened since the follow state was not what it should be after an unsubscribe action.
  5. In the bottom-right terminal, I verify that the unfollow actually happened by re-running sbotcli hist as above. A new message, number 22 appears with the follow state being set to boolean false.
  6. I now re-run the check in the top-right browser window to check the same follow state. It still returns true (a string), which seems to contradict the hist command I just ran before.

The reason that this came up for me is that if I now tried to re-subscribe to the same feed id, lykin would tell me "already following this id, no action needed" and disregard the follow instruction. The same happens for unfollow instructions.

Sometimes the state as seen by golgi seems to "catch up" after a while, but I haven't spotted why/how to arrive there.

Stopping sbot-go seems to consistently "flush" the state and everything works as expected once it starts up again. For one instruction that is, then we're back to this weird will-they-won't-they state.

Anyone got an idea of what I'm doing wrong here?
I get the impression this might be an index in go-sbot lagging behind, so that the raw messages are ingested but the updated follow state hasn't been computed yet. However, I'm running go-sbot with hops=1 so it shouldn't have anything else to do (it doesn't follow many people) and indeed, CPU usage is minimal.

FWIW, the code to retrieve the follow status in rust is pretty simple:


pub async fn is_following(public_key_a: &str, public_key_b: &str) -> Result<String, String> {
    let mut sbot = init_sbot().await?;
    let query = RelationshipQuery {
        source: public_key_a.to_string(),
        dest: public_key_b.to_string(),
        .map_err(|e| e.to_string())


#[post("/about", data = "<peer>")]
pub async fn about_form(peer: Form<PeerForm>) -> Result<Template, Flash<Redirect>> {
    info!("Showing follow information about peer {}", &peer.public_key);

    let whoami = match sbot::whoami().await {
        Ok(value) => value,
        Err(e) => return Err(Flash::error(Redirect::to(uri!(about_start)), e)),

    if let Err(e) = utils::validate_public_key(&peer.public_key) {
        let validation_err_msg = format!("Public key {} is invalid: {}", &peer.public_key, e);
        warn!("{}", validation_err_msg);
        return Err(Flash::error(Redirect::to(uri!(about_start)), validation_err_msg));
    info!("Public key {} is valid.", &peer.public_key);

    let follow_status = match sbot::is_following(&whoami, &peer.public_key).await {
        Ok(status) => {
            let success_msg = format!(
                "Follow status for {} : '{}'",
            info!("{}", success_msg);
        Err(e) => {
            warn!("{}", e);
            return Err(Flash::error(Redirect::to(uri!(about_start)), e));
    Ok(Template::render("about", context! { whoami, peer_pubkey: &peer.public_key, status: follow_status }))
User has chosen not to be hosted publicly
User has chosen not to be hosted publicly
@Daan %1OfDdldEwp1yc6OQGSSBQ0jJzbwxMNq5MEFJ9GTf828=.sha256

Thanks @glyph that did it!
Just tried, and it works!
And don't worry, I had fun writing my own checking function and all. I'm happy learning/practicing more rust and rocket as much as I'm learning lykin.

I guess this should also figure someone in the instructions... Is this specific to some part of my setup, or what is this librarian thing? :P

User has chosen not to be hosted publicly
Join Scuttlebutt now