@matt People seem to be creating unique identities for ferment -- so I'm starting to see a lot of duplicate identities. Why is that?

Installing Ferment, then I can find out!

Ah ha, Ferment fires up a seperate scuttlebot folder in .ferment. Which means not only will I have two identities, but I will also have two scuttlebot databases.

Why not just use the same .ssb folder so we aren't duplicating all of this work?

Hmm... I tried doing a cp -r .ssb .ferment to see if I could use my ssb identity with ferment, but no go.

@ev also see discussion in this thread: ferment announcment thread

we had some conversation around this yesterday and how this might be fine for multiple identities.
@matt is actually doing some interesting stuff with making sbots which replicate ferment users with higher priority

I bridged the networks by inviting a user from ferment to my pub, which then replicated ther other ferment users. If it's a pain I can get in there and un-follow and it will stop some of the dup'ing

@dominic hmm... I'm not sure forking the network is the best way to approach this issue.

@ev I agree. I want to find a middle ground where fermet can focus on music publishing, but can still interact with patchworld

@ev The latest batch of ferment leakage is my fault. I noticed some ferment posts in my patchwork data feed that weren't showing up (someone must have been using another pub with ferment) and I wanted to see if they'd get sucked across if I paired my two ssb directories on my computer. It worked perfectly. Only ferment feeds were replicated into my ferement instance and those missing posts showed up.

But the side effect was of course that my patchwork now has my ferment account as a friend, so it went ahead and 3-hop replicated me and everyone else on ferment. This is great for ferment because it means people can now use other pubs (not just my one).

I think the network is working as intended. We just need a better way of handling these duplicate identities. This is already a problem (lost keys, multiple devices). Me and @mikey had a good discussion about this last night.

@Dominic I have a short term proposal for handling at least the naming conflicts. Ferment could use a namespaced field for its name field. When someone changed their name on ferment, we'd generate this message { type: 'about', name: 'ferment_matt', scoped_name: 'matt' } ... or { type: 'about', scope: 'ferment' } (second option would require co-operation with other clients)

@matt I think we should be using the same identities in ferment and ssb. It's a distributed network, there's no way to avoid 'leakage' between the different networks -- unless you use a different protocol which kind of defeats the point I think.

I think if you want to present the same identity on ferment you should use the same key. If you want to present differently, then you should use a different key. In patchworld, multiple identities is useful for like, parody or troll accounts, and there hasn't been much demand for that yet.

But for musicians, they might want to explore a different sound in a side project. They'll put that music out under a different name, because they don't want listeners to come at it with preconceptions of their other work!
Or, they want to see how their new music stands on it's own, without tying it to their already successful identity.

Yeah I don't want to avoid leakage, I just want folks to be able to clean up the mess

I'm gonna add a cli option to ferment --use-sbot that won't start a server and instead will just connect to your local sbot instance like patchbay does.

And the other thing to consider is, in the future there will be a lot less crossover between patchworld and ferment, so the identities won't be duplicates.

I think the answer is to allow either. The user can choose to use system ssb or go ahead and create a new identity (and self serve).

@matt

in the future there will be a lot less crossover.

What makes you think this will be the case?

I think the answer is to allow either.

I want to be able to use my identity across ssb applications, so this makes sense.

Maybe the solution is to use the same database folder for .ssb, but use a different post type for ferment? This way if we want to build a ferment plugin into 'Bay we can do that and I can use my identity across ssb applications.

@ev yep! Ferment uses type: 'ferment/* for all of it's messages, so a plugin would be super easy

There are (besides the current duplicate identity problem) no conflicts in the messages.

My comment about less crossover in the future was probably a little rude to ssb. Sorry ssb -- I meant that in the future there could be a lot of people using ferment that would never use any other ssb apps. I should be more optimistic!

@matt I don't think it'd be the case that more people will use ferment and not use other applications.

If you think about the current state of the oldernet, many people use Twitter AND Soundcloud AND Github, so why wouldn't they also use ferment and {work, bay} at the same time?

It could also be that people will come in reverse in the future, where they get hooked on listening to music on the distributed Internet and then decide they want to see what's going on in the git-ssb world!

@ev yes, I completely agree and take back my earlier comment!

Ferment could be an excellent gateway drug to the ssb eco system

@ev great point, and also many artists maintain a twitter account presenting the same identity as their music, etc.

does ferment save the music you stream, or is it ephemeral? I live alone, and access the internet by tethering to my phone. Offline-first is a massive part of why I use patchwork.

it saves it - it's using webtorrent underneath.
check out your ~/.ferment folder

@Dominic says: In patchworld, multiple identities is useful for like, parody or troll accounts, and there hasn't been much demand for that yet.

rather than parody accounts, i think first-class support multiple identities are useful to everyone who has multiple identities from using multiple devices or everyone who has lost their key and had to create a new identity. or maybe i'm referring to "multi-key identity" (a system to allow multiple keys be grouped into a single identifier, and provide support for graceful key revocation) and this is different from this situation.