@mmckegg nice work on ssb-backlinks. i am updating patchfoo to use it now for channels/tags and it works. i also pushed a minor update: %pdhLGbq...

one issue: the dest-type-timestamp index seems to always get picked over the dest-timestamp one. the result is that the channel view is sorted by message type. it looks to me like this is a bug in flumeview-query; i am going to try to write a test case for it

opened issue on flumeview-query: %b+QdyLF...

example of results sorted by type:

$ sbotc backlinks.read '{"query": [{"$filter": {"dest": "@f/6sQ6d2CMxRUhLpspgGIulDxDCwYD7DzFzPNr7u5AU=.ed25519"}}]}'|jq -r .value.content.type|uniq -c
     18 about
    267 contact
      4 issue
      1 mutual/credit
    843 post
      1 pull-request
      1 vote

Thanks @cel

Published %pdhLGbq... as 0.1.0

@cel also thanks for spotting the path bug in ssb-private!

Have now merged and released it as ssb-private@0.1.1

cool!

Oh by the way, I just added improved #git-ssb integration into #patchwork. Whenever a git-link is clicked, it now checks to see if git-ssb web is running, and if it is will open using localhost:7718.

It also will attempt to spawn git-ssb web on start-up if it is available in the path.

Pretty hacky, but it has made my git-ssb workflow much nicer!

Sounds cool AND sounds like scope creep @matt !

@mix

sounds like scope creep

yeah I was pretty worried about that. But I'm thinking of this as a temporary hack until there is proper inter-app integration.

Once there is a standalone %patch-hub, it can expose itself to patchwork in some clever way as an "ssb external link handler".

the way @matt has done it minimizes the interaction, and that is good. Could we just render such links as git-ssb:<id> and use the OS's protocol routing stuff to start the relavant app? we could also do dat and ipfs integration this way.

@cel @Dominic

I'm starting to wonder if we should add asserted timestamps as an additional index to ssb-backlinks. Just realised I need this to make channel pages work properly for freshly onboarded folks.

This is already a fairly large index though, and this would make it half as big again.

https://github.com/ssbc/ssb-backlinks/issues/1

Could we just render such links as git-ssb:<id> and use the OS's protocol routing stuff to start the relavant app? we could also do dat and ipfs integration this way.

we had a similar idea here, copied below:

what if there was a JSON file in ~/.ssb (or part of the standard ~/.ssb/config) that mapped message types to shell commands to open those messages? kinda like file extension handlers / launchers in most operating systems.

so something like

{
  "post": "ssb-patchwork --open ${id}",
  "git-repo": "git ssb open ${id}"
}

this of course means implementing the necessary functionality in patchwork and git-ssb-web in order to open specific messages (and starting the electron app or web server if not already).

We should probably also think about "protocol handlers" e.g. ssb:// system wide.

so let's continue this train of thought. if we know how to open messages, then it shouldn't be that hard to write a module ssb-launcher which reads this config and runs the appropriate command. then we can all register ssb-lancher to handler ssb:// protocol links, if the links were in format ssb://${encodeURIComponent(messageId)}. would that work?

i'm okay with channels sorted by asserted timestamp. but i'm using ssb-backlinks for listing mentions also, and those i would want in received order. so i would suggest index by both

@cel Ah, good point. I should look into rewriting patchwork's mentions on top of it too.

The problem I can think of is that you only get direct mentions, not replies to your posts (unlike the way it works now). But it's probably not too bad.

I wonder if posts should contain an automatic backlink to the user they are replying to? It could kind of be like those dreaded twitter profile tags!

The problem I can think of is that you only get direct mentions, not replies to your posts (unlike the way it works now). But it's probably not too bad.

true. i wanted to include replies but didn't want to add it as a filter of the public feed because of the inefficiency. an index of messages that link to the user's messages would be doable i think, but more complex to implement.

I wonder if posts should contain an automatic backlink to the user they are replying to? It could kind of be like those dreaded twitter profile tags!

this could be useful for replication (along with adding the sequence number): %Bw6sVzo...

We could use a bloom filter for this! all messages that have some sort of reply (backlink, dig, reply) would be stored in a bloomfilter, which could be checked instantly.