Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
Connoropolous opened this issue Dec 20, 2015 · 10 comments
Labels

Comments

@Connoropolous
Copy link

No description provided.

@ahdinosaur
Copy link
Contributor

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 loomio/loomio#2800.

@Connoropolous
Copy link
Author

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
Copy link
Contributor

@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
Copy link
Contributor

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
Copy link
Author

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
#125 (comment).

@Connoropolous
Copy link
Author

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
#125 (comment).

@bhaugen
Copy link

bhaugen commented Dec 22, 2015

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
Copy link

gcassel commented Dec 22, 2015

@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
Copy link

bhaugen commented Dec 22, 2015

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
Copy link

gcassel commented Dec 23, 2015

^ perfect

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants