# Rebase
## Meeting 2022.03.25
Eric: Have the user load their contextualized information connected to their wallet.
Wayne: Must-haves.
Orie: Vision -> Work Mode -> Must Haves. How are DIDs and VCs used to discover how identifiers are related to each other. Portable reputation.
Oliver: Data models, binding cryptographically and other means the accounts.
Dan: Agree, verify bindings across identifiers.
Community Group Charter: https://docs.google.com/document/d/1sjzWsa33J6kSBH_X0CxI9DwYniwCTPG1rCJDFJz3SaQ/edit#
### Notes from Oliver
wyc:
agenda topics: wants to agree what are the must haves, what are the nice to haves, twitter, github, dns are must haves
then talk about what we need to define per each must have, e.g., verification method (evidence) type
joel:
2 layers:
- naming, ens/dns
- tieing to DID and where to store that inforomation
- how to format verifiable credentials
orie:
- high level vision thing
- descirbing how DIDs and VCs are used to discover how identifiers are related to each other, bitcoin, email, github, twitter etc.
- how are they related to each other and how DIDs and VCs can help with this.
wyc:
- forward compatibility with something like deco since this is going to change everything.
orie:
- we need to agree shared vision, and work mode
- basic amount of work mode skill is needed
joel:
is the goal to come together to have a standard way and example implementation
create proof to create a web2 account with a DID
danial:
agreed
eric:
we should with this group but then we can bring in more companies
but if we all go a separate ways, that would be not great
we should all agree that all DID, web3 wallets, dApps validate someones profile and it should be a universal way to sign up.
orie:
there might be a subset of it that there might be ppl that might do it in a different way,
to succeed, at being the best, wants to meet in a recurring manner.
eric:
do you really want to part of this joel? and want to join a bigger colelctive and do the same thing?
joel:
we have built a service with twitter, github but it is live, but not raelly in production. we didn’t have a lot of time to focus on it. this effort seems great because the ppl fit. would be good to have a place where we have a place
wyc:
we also have such a service similar to joe, similar interest.
i have chartered a whole charter for rebase for a CCG at W3C
orie:
alternative is existing WG and apply to both to DIF and W3C CCG.
alternative approach and create a github org out, draft stuff, don’t deal with other groups but we you plan some artifacts to go to some standards group.
if you want to get bigger guys to participate.
eip is more permissive, ccg is less permissive since lawers need to come in place
ori:
in order to be successful, it has to be large players with significant brands, contributed to its development
eric:
definition of that brands is important, no need for having goolge, amazon
orie:
what is success in 5 years from now?
- twitter, kraken, square, meta using it
5 years from now are using rebase credentials to link
what is failure?
- it is a draft in a community group maintained by a bunch of startups
wyc:
is it seriously considered specifications that the FTC would consider when it drafts policies for big tech giants
eric:
agree initial set of companies are web3 wallets, dapps
target market should be both, web3 and DIF ppl
orie:
web3 and social networks (web2)
joel:
what is the use case for applications actually verifying these proofs?
wyc:
use case doc
orie:
similar to verified email, so it would be good to have a verified twitter account or social media account
faster than traiditional approach
wyc:
1.
2.
wyc:
start with a github organization
defer to decision where to home it
we consider, w3c, dif, casa, ietf etc. but no decision today
and meet bi-weekly
eric:
question to wyc and joel?
connecting proofs together is one thing, discoverability is another thing and is needed? and joel has done some work on it today
orie:
let’s defer discovery conversation until we have some credentials
dan:
joel:
definitely a worthwhile convo how to discover things but there too many aspects of that, there are so many types of use cases, let’s focus on structure.
wyc:
discoverability might be different from use case to use case
instatiating the user’s context based on differnt stuff, e.g., after sign-in with ethereum
let’s focus on data models and verification first
orie:
work mode is rebase.xyz,
rebase.org is in DIF already
we should fix branding
we need a github org for top-level branding to get ppl to start organizing
rebase.xyz is the external facing brand
wyc:
rebase.xyz fine
eric:
bought the domain, also fine
orie:
fix github org, rebase.xyz
we should get a marketing website for rebase.xyz
we can align specs underneath that
not under DIF, just extract out of DIF
no point in leaving it in DIF if there is no contributions
wyc:
most imoprtant things until next meeting:
- updated vision
- meeting time on the calendar
- mocks for a website for rebase.xyz
orie:
- cannot help with no marketing
- cannot help with specific schemas, but help refining them
- i will help with spec
wyc:
- can you check existing schemas that are in the repo @joel?
- what are relevant verification flows to you in your systems?
- i will help with marketing
- continue discussion on existing schemas and load vision in a PR
eric:
- will send out meeting invite for next meeting
orie:
- need also figure out eidtor chair roles