pitherandd
Joined 7 years ago
Joined 7 years ago
The more I read this reply, the more I agree with it, and I think it may actually not be that difficult of a change. Card sets could be integrated into the existing cluster concept and I could just give users the ability to choose which sets (clusters) they swipe on and the weighting that they apply to each. They could also decide which clusters should be factored into their similarity matching. I _think_ this will all work with the existing CUBE concept, which is exciting, because many other proposed solutions by others didn't fit nicely within that mathematical structure.
You've honestly given me a lot to think about and I think I see a better way forward now. Your insight really increased my mood because I think you've discovered something very important that I am likely going to be spending quite a bit of time on in the next coming weeks and months.
Thanks so much!
I actually really like your mock-up and really appreciate that you took the time to make it. Hopefully you don't mind if I take quite a bit of inspiration from it, because I definitely think it looks much better than my current one.
Yeah, I agree that the network effect is one of the biggest problems. Retention seems very tricky with a concept like this because while posting it to reddit or HN can result in many registrations, few people stick around because there isn't much to do on the site because there's so few users at the moment. It honestly does make motivation pretty difficult, but I am indeed going to stick with it regardless.
With regard to your last 4 numbered points, currently 0% == not answered == neutral, and this is mostly due to technical limitations. Your default similarity cube is just (0.0, 0.0, 0.0, 0.0, 0.0, ..., 0.0) (50 zeroes), and voting on cards adjusts this accordingly. Such that if you answer 100% to every card in the first cluster and answer no other cards then your CUBE would look like (1.0, 0.0, 0.0, 0.0, 0.0, ..., 0.0)
I was thinking about a potential way to solve this, but as of right now due to the constraints of CUBE similarity matching, this is the current solution.
Thanks again for such an insightful reply!
So, the problem we'd like to solve is what set of 250 or so cards has the highest predictive value in that similar answers lead to the best interpersonal matches?
The problem with hobbies is that there are so many of them and not many people feel very strongly one way or the other about many of them. You probably wouldn't not give someone a chance just because they prefer ping pong to pool, for example. Rather, I was looking for what might be deal-breakers.
The Interests page and tagging in general is what I am hoping will fill that need of specifying your individual interests and matching based on them. Here is where you can tag yourself with whatever you'd like and then search for users and posts based on these tags. The card swiping's function is mostly just a first-pass elimination filter.
I had the thought of perhaps doing categories instead with regard to cards. For example, sense of humor is often very important in people. Perhaps 50 of the cards should be memes? And then perhaps 50 of the cards be political, 50 of the cards be hobbies, etc.? Or perhaps there could be multiple similarity percentages, each of a different category? It's still very experimental and I'm not sure what the correct path is.
For authenticating with Google and Facebook I used the oauth2 crate.
For logging in in general I used private encrypted cookies as described on this page: https://api.rocket.rs/v0.4/rocket/http/enum.Cookies.html
I used a Request Guard that decrypts this cookie into the corresponding user identifier. Here's a link to that page: https://api.rocket.rs/v0.4/rocket/request/trait.FromRequest....
I've been working on this for a little over a year now, off and on.
Let me know if would like me to expand on any of these points.
I'm using tokio-postgres for my database library and both it and Rocket are async, so they synchronize very well together. I do not believe Diesel is currently async, but in either case I'm using tokio-postgres instead so I haven't had to look into how to integrate Diesel with Rocket.
Other than that, my needs were pretty simple and I used well-supported platforms, so I haven't really run into any major issues yet.
Pros:
1) Allows for instant similarity-searching. I am using the Postgres CUBE data structure to index users' votes and it has a limit of 100 items. So, if I didn't use clusters then there could only be 100 cards maximum, but ideally you would have even less than that because the CUBE can start to slow down when you approach that limit.
2) It's also a bit of a privacy feature as people can only see how you voted along cluster lines, and not how you voted on individual cards. This provides the aforementioned plausible deniability.
Cons:
1) Not all clusters are ideal, as you've seen. I spent a lot of time exploring different clustering algorithms and none of them were perfect. Some cards were naturally a part of multiple clusters and others didn't align to any at all. I'm sure a lot of this comes down to card choice, which I definitely could improve.
2) Can be confusing to users as opposed to just listing theirs and others votes on cards.
---
If you'd like to help and create better clusters, I'd definitely be open to tweaking them. Most of the required data can be found by navigating to the Cards page. For example, if you go there and click "War on Drugs" and then click "View Correlations", you'll find that "War on Terror" correlates the most with "War on Drugs". This data can then be used to try and create your own clusters. I've found it to be a very tricky puzzle satisfying all the constraints.
In the end, for performance reasons, I felt like I had to choose between either having clusters or only 50-75 cards, and I chose clusters. There's probably a better way of doing it, but I was unable to find it at the time.