Is holodex intended to be able to reason about people signing in? or is it read-only?

[ahdinosaur]

yep, Holodex needs to support auth as soon as we try to support non-public reads or any writes, which we want to do.

what's on your mind @Connoropolous? related to https://github.com/loomio/loomio/pull/2800.

[Connoropolous]

yep, essentially @ahdinosaur. I was also just wondering generally about the degree to which holodex was being designed to act as a platform, versus a more brandless tool, which the read-only way would act more as.

[ahdinosaur]

@Connoropolous

in my mind Holodex is being designed as a tool focused on people, groups, and relationships within an ecosystem of modular apps. this comes out of the union of passion between the main contributors @simontegg and i, who want to improve infrastructure for human organizing systems, are better at technical over business development, favor interoperability over intraoperability, and love beautiful data visualization and elegant data models, respectively. at the moment, Holodex is also a product of our free time, so our capacity is limited and our short-term delivery shows but we're committed to the long haul.

so, what are you most interested in seeing Holodex as?

[ahdinosaur]

mentioned this @simontegg, he understood the question of "platform versus brandless tool" as both a question of a branded app versus a white-label app and a question of a specific app or a general app. so maybe a better answer is that our shared strategy at the moment is to create generic and extensible white-label back-ends and front-ends that provide solid user interaction to support most relevant use cases, which other folx can use to experiment to brand apps with various user workflows. as a concrete example, this means we would create a generic value planning and accounting back-end API using the Value Flows vocabulary, which can be used to power targeted workflows that users see like Cobudget and my.enspiral.

[Connoropolous]

This is a great and useful articulation. Building Metamaps, we thought we were building a tool, and then all of a sudden we were building a hosted platform, and having confusion internally about those things did not serve us well at all. On Dec 21, 2015 8:50 PM, "Mikey" notifications@github.com wrote:

mentioned this @simontegg https://github.com/simontegg, he understood the question of "platform versus brandless tool" as both a question of a branded app versus a white-label app and a question of a specific app or a general app. so maybe a better answer is that our shared strategy at the moment is to create generic and extensible back-ends and front-ends that provide solid user interaction to support most relevant use cases, which other folx can use to experiment with various user workflows. as a concrete example, this means we would create a generic value planning and accounting back-end API using the Value Flows vocabulary https://github.com/valueflows/valueflows, which can be used to power targeted workflows that users see like Cobudget https://github.com/open-app/cobudget and my.enspiral.

— Reply to this email directly or view it on GitHub https://github.com/holodex/app/issues/125#issuecomment-166476970.

[Connoropolous]

So far, how I've understood the biggest value prop of holodex is as an avenue for 'exploration of what is'. If done right, this would be a powerful thing, because providing strong pathways from end users to things they didn't know, but that would interest and empower them, within network boundaries, could level up the self-reflexive capacity of the group as a whole.

Without even getting into data creation, like we ventured into with Metamaps, this challenge of visualization/ exploration in terms of user experience would be a full one on its own. On Dec 21, 2015 10:18 PM, "Connor Turland" connorturland@gmail.com wrote:

This is a great and useful articulation. Building Metamaps, we thought we were building a tool, and then all of a sudden we were building a hosted platform, and having confusion internally about those things did not serve us well at all. On Dec 21, 2015 8:50 PM, "Mikey" notifications@github.com wrote:

mentioned this @simontegg https://github.com/simontegg, he understood the question of "platform versus brandless tool" as both a question of a branded app versus a white-label app and a question of a specific app or a general app. so maybe a better answer is that our shared strategy at the moment is to create generic and extensible back-ends and front-ends that provide solid user interaction to support most relevant use cases, which other folx can use to experiment with various user workflows. as a concrete example, this means we would create a generic value planning and accounting back-end API using the Value Flows vocabulary https://github.com/valueflows/valueflows, which can be used to power targeted workflows that users see like Cobudget https://github.com/open-app/cobudget and my.enspiral.

— Reply to this email directly or view it on GitHub https://github.com/holodex/app/issues/125#issuecomment-166476970.

[bhaugen]

Do you think the network of apps idea fits into this discussion?

The idea there was that you would have your own personal agent, an extension of Personator (becoming Impersonator). Your Impersonator would meet other Impersonators, and they might form groups, which would be another type of (group) agent (Grouponator? (no, that's a horrible name, will remind people of Groupon)) living on the Web. And they would visualize their groups with Holodex.

In other words, in this scenario, the groups would form out of the interactions of agents.

Of course, Holodex will first be used to visualize existing agent relationships (e.g. Enspiral or NextEdge or the VF gang).

P.S. @ahdinosaur, I love "favor interoperability over intraoperability".

[gcassel]

@bhaugen do you think the possible extension of Personator into Impersonator could enable people to not only limit the info they share with particular communities, but also, to create secure pseudonymous usernames when desired? I hope so! I believe that's ultimately a necessary (advanced) topic for community-building, per this great essay: http://www.wired.com/2014/04/why-we-need-online-alter-egos-now-more-than-ever/

I'd like to start from the premise that the ability to use pseudonyms can create real value, and is a tool which should be available for agents within communities that allow it. If anyone is inclined to dispute this perspective, I urge them to read the link above-- but certainly feel free to discuss any concerns with me.

[bhaugen]

I don't see any limits on how many Impersonators people can create and use in different contexts.

That sometimes interferes with trust within a community, but that's up to the community to deal with.

[gcassel]

^ perfect