I think this may be a superset of Viktor’s dinner carousel
but apparently closed source meetup.com has been acquired by some corrupt corporate who is threatening to charge rsvp users $2
7 Likes
Yes! Core functionality of any group. Check out scuttlebutt SCRY for interface and design inspiration!
3 Likes
Has there been any work done here?
I don’t know of any updates to this app idea. If no one has started anything on this yet, how about creating a list of functionality that this app should have in the first version (initial scope)?
1 Like
I’d like to see
- organizer can create a group
- member can join a group
- organizer can create an event for a group
- members are informed about the event
- members can join an event
- organizer (and members?) can see the list of members of an event
Maybe later one
- members stake some tokens when joining an event
- organizers confirm attendance and thereby release the tokens
- tokens from members that did not attend are send to the organizer
There are some existing open source UIs for such an app:
And:
1 Like
Thanks @friedger
Can anyone be an organizer or a member?
members are informed about the event - how should they be informed?
member joining an invent - register for an event ahead of time right?
Do you want to disallow a member register for multiple events that happen at the same time?
see the list of members of an event (what info do they see? names? handles?)
Just thinking out loud what other than basic CRUD & links are needed to support your first list of functionality.
1 Like
Good questions, here are my naive thoughts about them:
Yes, absolutely, and anyone can be both.
Ideally, there is a messaging service described in the DID document that belongs to the user. (https://w3c.github.io/did-core/#example-15-various-service-endpoints)
Yes, that is what I meant.
Interesting rule. Does the society would agree on this? Currently, it is common to have overlapping commitments (reading facebook while having coffee with a friend). Probably the majority would find such a rule too restrictive. However, would it be possible that this is a property of an event or group? A group could decide that attendees are not to allowed to register for the event if they have already a commitment or are removed from the list if they commit to another event for the same time.
For humans, I would say they can see names. I am not sure how the identity system work on holochain, maybe users can define a new identity for each group.
I think the next step would be to diagram the core model which describes the core concepts/entities, how they relate, and the contract (in terms of functions) for each of them. Does that sounds reasonable?
1 Like
I would like to better understand how a holo solution would be different to lets say a smart contract solution or centralized solution.
I envision that the holo solution should make it easier for locally close groups to collaborate (without effecting groups on the other side of the world), maybe also for topically close groups. Furthermore, could communication between group members follow rules related to the group more easily? How would reputation and protection for group members work? How to avoid spam?
Is validation the answers to these questions?
Hi @friedger,
Very good questions! I’ll just share my thoughts here, based on my limited understanding of smart contracts.
Smart contracts, as far as I know, implement logic you want the contracts to enforce and the validators (however these are defined within the platform) will validate the transactions requested on the contracts. Depending on the platform the set of validators that need to perform the validation vary. If it needs global consensus that everyone in the network validates, it gets expensive and slow - the scalability problem that comes with global consensus. If the platform only needs a certain set of validators to validate the contract, how are the validators selected (would the algorithm of choosing validators bias certain segments of participants?) ? Languages used for implementing smart contracts are platform dependent, most folks are building on top of Ethereum, I guess.
With centralized solution, it’s centralized, so a centralized organization controls everything. Let’s just take meetup.com or eventbrite.com as an example, the platform sees the info that are shared by members and decide what they want to share and keep to themselves. The centralized platform is a middleman that intercepts all the traffic and decides what it wants to let through or block, which impedes community collaboration and takes away control of data & decisions from individuals. It’s difficult to move your meetup group (the community in the group) out of the meetup platform today.
Holochain let you build rules into the hApps, so you can build your own rule for each local community. I think you could do similar thing with smart contracts which would have to be community specific, and then again, who validates? With centralized solution, it’s whoever owns the central server that decides how they want to connect or not connect individuals.
So I think it’s how much autonomy the platform is giving its members as well as validations of the community code/rules.
I’m interested to hear your thoughts.
1 Like
Here is an overview of entites and how they interact:
As a first POC, the top part with group events and group event RSVPs would be enough.
Validation rules would ensure that events are only created by group admins and that RSVPs are created by the user.
2 Likes
Hi @friedger, thank you for sharing your diagram! What you said sounds good - starting with group events & RSVPs. How are group admins defined/created? It can be whoever creates a group and they automatically becomes the group admin, and then they can assign other users to be admins of that group? Any admins can then further add/remove group admins? Maybe we keep it simple, and only let the owner have the privilege to manage group admins, but other admins can create/manage events for that group? Or just one admin (the owner) to start for now?
@lchang Introducing owner roles is a good idea. Owners can manage admins, admins can manage events.
For now, the creator of a group is the only owner and admin.
Roles would probably another entity and the verification would include rules to ensure that actions are only performed by users that have the appropriate role.
Sounds good, @friedger. This could probably leverage some design patterns that @pauldaoust laid out in the forum, maybe capabilities and others or some combo, also should look at reusable zomes and/or mixin traits that others might be working on. As for the events, do we put a limit on how many RSVPs are allowed, or should we leave it open for now?
Hi! Just going over this, wanted to share https://github.com/eyss/holochain_roles, a roles reusable mixin. Although it does not support setting roles for an specific entry yet (it only supports setting roles that are applicable to the whole DHT), this should be an easy enough functionality to add.
3 Likes
heya all!
Given that we might be starting an event space here in my Village, I’ve done a little deep dive into the needs as I see them and did some work on a first draft open design of a hApp for space bookings AND events. The two zomes could be two fully seperated apps but I would love for them to work well together.
Here is the design doc:
What do ya’ll think? Buildable? 
5 Likes
Oh man!
@ViktorZaunders - this is fantastic! I can’t validate from the technicality of what you’re showing here, but can absolutely say that we need this hApp, and I’ve heard lots of interest in this one.
@tats_sato, @RobLyon - does this look like it’s in the green zone of Viktor’s scale (inside the hackmd) to you?
Also, I love the name Coalesce.
@guillemcordoba I could be wrong, but if it’s just a generic roles library, couldn’t you just create a role like editor_of_<entry_hash> for each individual entry you want to enforce roles on? Sounds to me like it’s already ready to go, although I guess maybe you’re suggesting that this could be a built-in feature in the future.
So you’re partly right, but the main difference is that that mixin assumes the progenitor pattern, which is not what you always want when you assigning a role for a particular entry.
I don’t have a clear way forward to not enforce that pattern, maybe they are two different mixins altogether. If you have any thoughts, let me know!