yes please!! I would love something like Loomio on here. Loomio is a very focused sort of pole explicitly for making clear decisions - it's meant to surface difference and encourage discourse and adaptation, not polarisation.

If you copied that format, the design part would be mostly done (and I can easily detail it, because I helped make loomio).

In terms of architecture it would touch a good amount of things. I think you could learn a lot from following the work done in patch-gatherings (though I think we've learnt some and this would be a great chance to iterate a little).

https://www.loomio.org

here's a video of how loomio works (I made this with @robguthrie, and @Alanna - who is voicing it)!

https://www.youtube.com/watch?v=fuWfEwlWFlw

@josiah or bookmarks/curation!

yeah bookmarks (local/private and public) are a cool idea.

also an entry point to an exciting rabbit hole : decentralized annotation, curation, and knowledge management!

hey @Josiah

So, after looking at patch-gatherings last night, I wrote up what I think would be a good set of messages for a little bookmark system.

this looks really good!

archive and favourite are basically just "first-class tags" here, but would allow the interface to have standard form of organization.

i think it's great that you named this. i don't think we want "first-class tags". if we provide only normal tags, then different interfaces can choose their own standard form of organization. we can index the tags in flume so that all lookups are fast, regardless of how they organize.

Would [private/public bookmarks] be as simple as using the same messages but deciding whether to send them as private messages or public messages?

as far as i know, yes!

this is a random idea, what if instead of a new bookmark message type, we re-used the about message type?

{
  type: 'about',
  about: '%...',
  name: 'that one time',
  description: 'why this is important',
  tags: [#archive, #favoruite]
}

would that work?

if you followed the gatherings model the about messages would be abouts on the bookmark, so you'd have an original bookmark

// key for this bookmark %qwerty1234
{
  type: 'bkmk',
  bkmk: '%abc123',  // the content you're bookmarking
  name: 'that one time',
  description: 'why this is important',
}

then you might tag the bookmark later :

{
  type: 'about',
  about: '%qwert1234',  // the bookmark message
  tags: ['humour', 'wellington']
}

or 'delete' it :

{
  type: 'about',
  about: '%qwert1234',
  archived: true
}

Personally I think having the bookmark be a seperate message has advtantages - like you can just ask for bookmark messages and you don't have to make magical parsers for all the about messages to know if they might have been bookmarks.
You also get to use about messages to modify the bookmark nicely. (Though I guess if you did go with about messages, your about messages could have about messages ... meta-about!!)

@cinnamon about messages don't over-ride unless that's how the interface wants it. For patchcore, it's common to just want to most recent edit. Sometimes you also want the most recent editition each person has declared.

Personally I think having the bookmark be a seperate message has advtantages - like you can just ask for bookmark messages and you don't have to make magical parsers for all the about messages to know if they might have been bookmarks.

@mixxx

personally, i think making the bookmark a separate message is a smell. as in, it creates another layer of indirection that adds more complexity for questionable benefit, so i'm not sure this is a good idea.

for context, i'd much rather a "bookmark system" is really a flexible curation, annotation, and knowledge management system. in this context it makes sense for the about messages to reference the messages being annotated, not some "bookmark" message that references the message being annotated.

another way of saying this: are bookmarks really the same as posts or gatherings? i think bookmarks are really ways of organizing posts and gatherings, and are not "sources of content" in their own right.

if i have a bookmark about message A and you have a bookmark about message A, are they really different bookmarks? isn't what we say about our separate bookmarks really what we are both saying about the original message?

i also think we shouldn't be concerned about "magical parsers". we can search for all about messages that reference messages (not identities), these are "notes about messages". of these messages, we can organize them by tags, so i can catch up on my #longreads posts. if we have the bookmark indirection, i'd wonder how we resolve the two bookmarks for the same message problem, i don't really want to see the same post show up 6 times in the same #longreads list, just because 6 people chose to tag it.

so i guess i'm saying, @Josiah i think the simplest way to start implementing a bookmarking system is with about messages that reference other messages and have a tags key.

we'll need a new flume index which looks for about messages with tags keys, which provides a lookup for userId -> tag -> messages. so i can see the current messages marked with a specific tag, or all tags marked by a specific user. then we can re-use the existing ssb-about index which provides userId -> message -> about to see the current tags for a given message.

this is my recommendation because as far as i can tell it's the smallest change to provide the basic bookmarking functionality, as this only adds the concept of tags in about messages yet provides enough information to ask the question "what are my favorite posts from Scuttlebutt?".

also, i hope i'm not projecting my ideas on to you. i've been thinking about a bookmarking system for some years, had some chats with @Iain recently on how to make this happen, and only until your post about did it finally "click" on how to do this in a way simpler way than i was thinking before. so thanks.

good question about editing

@mikey you sold me with this argument

if i have a bookmark about message A and you have a bookmark about message A, are they really different bookmarks? isn't what we say about our separate bookmarks really what we are both saying about the original message?

@Josiah

Are you not able to filter the messages by the author?

yeah we can do that, also in the index we can key by author.

I've seen flume mentioned around here a number of times but I've never used it; is there anything you would recommend looking at to get a sense of it and how it's being used?

yeah good question, there's very minimal documentation for flume. i'd recommend checking out ssb-about, ssb-friends, ssb-backlinks, patchwork/sbot/subscriptions, patchwork/sbot/channels. in our case we'll probably want to re-use ssb-about and create a special index for tags using flumeview-reduce.

Is it necessary to have all the fields? Or could you do it incrementally with several about messages? Again this way of doing it I got from patch-gatherings, not sure if there are other arguments against this.

yeah you can do it incrementally with several about messages. the ssb-about index will get the latest about fields from each user about every message. so "editing" some value in your about messages is a simple as publishing a new message with the same key and a different value. (this would be how you could remove a bookmark from a tag, you publish a new about message with all the tags except the one you want to remove.)

Would you indeed have to make about messages about those about messages or could you just have multiple about messages and be able to reduce them into a single bookmark?

all about messages about any given message can be reduced into a single conceptual "bookmark" for that message.

@mikey you sold me with this argument

@mixxx

i actually am having second thoughts meow.

so imagine we decide to copy the gatherings pattern to make editable posts, as in you create a { type: 'post' } and publish about messages to update the post content.

i'm not sure if that's even a good idea, but it does seem like that's editing the actual message, and maybe with bookmarks we are editing an indirection to the message, so we should publish a { type: 'bookmark' } (or type: 'note') and then say things about that message rather than the original message.

i'm curious what @dominic or @cel or @matt think about this approach to bookmarks.

mmm, there can't be a cannonical source for message types @cinnamon - this is the subjective web remember. Having said that, I think a good pattern would be for people to publish clearly the schemas they're using ... somewhere. I made a start by adding to this repo https://github.com/ssbc/ssb-msg-schemas - it has validators which check whether a message has the parts needed for whatever you're writing to be able to uses it.

hey @cinnamon

If we decide that the newest about message always wins*, the way to edit an about message (such as a bookmark) is just to publish another copy of it to supersede your old ones.

*for a given user and target ref

ssb-about (which is used by Patchwork and Patchbay) already works this way.

in more detail, it uses flumeview-reduce to read all the messages you have in your database and creates an object that stores the latest about message result for each targetId -> field -> authorId. this is serialized to ~/.ssb/flume/about.json.

so to find the latest name for me by everyone, where value is the latest reduced value, the target of the about messages is my public key, and the field is "about": i'd go value['@6ilZq3kN0F+dXFHAPjAwMm87JEb/VdB+LC9eIMW3sa0=.ed25519'].name and receive an object where the keys are authors and the values are their latest names for me.

or in the command-line with jq:

cat ~/.ssb/flume/about.json | jq -r . | jq '.value."@6ilZq3kN0F+dXFHAPjAwMm87JEb/VdB+LC9eIMW3sa0=.ed25519".name'

Having a chain of about-about-about messages referring to each other feels more complicated to me. What happens if you make a tree shape instead of a linear chain?

sorry i didn't mean a chain of about-about-about messages referring to each other, i meant a set of about messages that all refer to a single message. to update a field value (for example: updating your name, or updating your name for someone else, or updating the tags on a bookmark), you post a new about message which references the target message, which includes the key you want to update with the next value.

Are there any docs describing the assumptions around each of the message types? I see this on ssbc.github.io but it's incomplete. I'd like to see how each message type is typically flume-reduced.

as mentioned in %zI07XPN..., i'd recommend checking out ssb-about, ssb-friends, ssb-backlinks, patchwork/sbot/subscriptions, patchwork/sbot/channels

hi @Josiah, i started a work-in-progress pull request to implement a proof-of-concept for what i was thinking: https://github.com/ssbc/patchwork/pull/675

Would it be helpful for me to share what I've done so far?

always! my pull request isn't functional, it's a mess of half-wired up scaffolds.

When I apply multiple tags to a bookmark I've only been able to get access to the last tag so far (this is what I'm looking into right now)

that's by design for about messages. you need to publish each about message with an array of tags.

I've been working on the model with a specific bookmark message and then about messages posted about the bookmark. I'm not sure if this will end up being the best approach but it seemed like a more straightforward place for me to start.

sweet. i think you should continue with whatever you feel best about, especially with regards to how you want to learn.

for me personally, after the conversations in %QRrL2wc..., i'm doubling down on my approach of publishing tags in about messages that link to the posts, since it can be applied as flags which i think is a very important moderation feature.

I tried saving the tags as an array but that didn't seem to help either (the tags in the observable coming back empty)

yeah, i had this problem, i fixed it with https://github.com/ssbc/patchcore/compare/tags.

Hey @Josiah!

re how to query: you might want to check out this sbot questionaire thread. I think it gives a very good introduction into what query tooling to use for which job or what is possible with which tool.

HTH

@Josiah

api.about.obs.groupedValues(id, key) is a function which given an identifier and a field key, returns information about the field key, in an object { [value]: authorIds }. this is used for example on the Patchwork profile page, where all your names by friends are shown, which who said that name on hover.

api.about.obs.valueFrom(id, key, author) is a function which given an identifier, a field key, and an author id, returns the latest value from the respective about message field. i think this is what you're looking for.

as an example of what i did using these function, see here.

@Josiah ah right, sorry. i'd repeat what i said in %zI07XPN... and %cyl8rmf..., we should do this in a flumeview.

we'll need a new flume index which looks for about messages with tags keys, which provides a lookup for userId -> tag -> messages. so i can see the current messages marked with a specific tag, or all tags marked by a specific user.

@matt what would you recommend as an index order? userId -> tag -> messages, or tag -> userId -> messages, or?

I'm really interested to learn more about flumeview. Ive looked at it a bit but didn't get it easily.
Id anyone writes documentation or a guide which makes it more accessible (understanding where it sits, how to plug it in etc) that would be awesome

every bookmark is required to have a tag

i'm not sure i understand why every bookmark would be required to have a tag, if we want to find all messages bookmarked by a specific user. if a "bookmark" is when you publish an about message which contains a tag for that message (the approach i'm exploring), then we can collect all these messages into a nested object where the first key is the user id, the second key is the tag, and the value is an array of message ids. with this nested object, we can find all messages bookmarked by a specific user by taking the first key as the specific user, and flattening on the second key to get all messages from all tags.

also i'm hearing from @mixxx and @Josiah that #somebodyshould write some #documentation for #flume. i'd love to but i don't know where to start, is it possible to document via a conversation? as in, if i was the "domain expert", could y'all ask questions and formulate the answers into documentation?

is it possible to document via a conversation?

The idea of that is very appealing to me, @mikey. I also have a couple of nebolus questions which i'm having trouble to clearly state.

How about doing a on topic call over mumble for instance and we later release the recording as a open-mic/podcast kind of thing so everybody can benefit from it and distil it into better written documentation?

ofc we are then back to the problem of finding a time that fits everybody but we managed to do that across three continents in the past with the project managment calls...

love it!
I think mumble plus a shared hackmd or similar in which to scrawl notes would be excellent.

When is a stable non-traveling time for you @mikey ?