Guang Guang
i guess it will eventually but its definitely not one of the priority items based on what we hear on slack.

Kind of makes sense. It would be great for the community members like me tho. 95 DCR is a pretty high barrier-to-entry at current prices

and really the community has grown and thrived since then. I am really impressed with the quality of the project

The community here seems great indeed

Even in the Brazilian community few people are currently testing.

A community member, I think @hoan.

Not sure, a community member met on Slack

Hi all. The community member who created this group has been MIA for some time and didn’t delegate full administrative rights to anyone (so we can’t promote new admins, make certain group changes, etc...). As such I think we will need to create a new group.

I do not want to condone a culture of split purchasing if it yeilds a voiceless community.

is there anything that can be developed to create health in this community?

I would suggest these issues are something the community will need to come to CONSENSUS about. Is there any more thought in play other that what @matheusd left on github?

I completely agree David. Maintaining security and robustness is the key. For me this requires a balance of simplicity and effort. Complex path toward a solution: @ the pool operator level, we align split purchasers by voting preference. This seems preferable to alignment of investment weight. The pluses outweigh here, in that we increase our voter representation by a magnitude. With alignment, we can specify that splits must be purchased in multiples of the minimum unit. Doing so allows the software to represent "Voices" in the TotalTix*(Totaltix/MinSplitCost) range or 40960 * (40960/5.03)=335million ‘Voices’ versus 40960, range in optimal conditions. Understanding that this method leaves buying votes down to your net worth, it simultaneously enfranchises the ever more diluted small user. There are some big issues with this idea, but the core of it is that we didn't think we'd have to address governance and voting expense this early. To address this, we may have to think through how we Scale the governance, and we will apparently have to do so (scale), every time the current tix algo incentivizes users opting for splitting. Another incentive to split, is to decrease the amount of time the majority of your capital is locked. As the pricing algo increases the competition for tix, and thus price adjusts higher, the ‘cost effect’ will magnify the ‘time locked’ issue. That's an economic driver and will intensify cyclically many times in the future as the software grows, unless we coordinate the development of the pricing algo with the development of the splitting software. Simplicity tells me, that the plus to be gained yields an outcome worth the effort. Ultimately I'd like to see an environment of UI integration wherein users can see what's on the table, self-align into purchasing/voting cohorts, and we'd only be adding another UI/logic layer, and not rewrite anything fundamental. By aligning at the VSP layer, we create an 'easy to integrate into Decrediton' path, in that we model and test the logic outside of Decrediton, and then consider integration. Problems that I see are: security, anonymity, meta-data. It's got to be a cryptographic solution. I see the matching method as: hashing voting preferences, matching hashes and minimum contribution blocks, and developing a ‘mini- quorum’ on a ticket purchase event. Analogize this: Senators (full ticket holders) and Representatives (many voters in a pool). But GROK this: we attain DIRECT DEMOCRACY for a magnitude more users than we have now. It’s a complex path, and it’s hard to state the value of the goal. It’s very complicated to understand if this kind of Direct Representation is worth the effort. I feel the plus could become the topic of conversation and the goal. Sometimes implementing mainline beta drives out the problems. Sometimes it drives out the solutions. In this case, I hope we drive out the vision and the architecture, instead of implementing a ‘patch’ mentality. I have been intending to develop this talk here, amongst splitters and operators to give the conversation to the masses as it were. Done well, this might also yield high levels of community inertia.Thanks for listening, I’m really new to this project, and clearly, this is meant to provoke thought and contribution onto the idea of scaling our ability to represent group thought, intention, and effort. Engagement and Representation are some of the core issues that created Decred. That weighs on my mind often.Thoughts/feelings?

what I don't want to do, is isolate this convo to devs, nor not include the constituents. that's where weird politics have hurt other projects. this community is already highly educated.

thanks david, but my time on slack is ... metered. certainly, I could put forth a proposal, but this is a bigger issue than any one should solve. it's gonna take a community, and I thought here may be a place to plant seeds. Also, I am unwilling to put forth a Pi proposal without a dev team to pull it off; i'm not trying to lay the work on somebody else. I don't think this concept is worth doing until it is developed further. you are right it needs more experts. I was hoping we could all ask questions of it until it improved to a presentable state.

Nope. Just another community member like yourself!