oddsdk / collector Goto Github PK

Goals

Goal: Demonstrate scale-neutral user-driven paid persistence of data.

Rationale

What does this demonstrate about ODD?

How does this support hackathon participants?

How do we measure success?

Details

ETA: 2023-11-11

Related Issues

Goals

Core: Get ODD SDK working and persisting WNFS in a React Native context.

Stretch: See if it builds on Android. We should give this a shot and only go so far as to provide initial documentation on the build issues if it doesn’t work for free.

Rationale

What does this demonstrate about ODD?

1. That it works in a native mobile context!

How does this support hackathon participants?

1. Provides a re-usable ODD/WNFS library that works on native mobile.

How do we measure success?

To what degree should we verify ODD SDK is working?

Details

ETA: 2023-11-11

Related Issues

#2

Goals

Goal:

• Demonstrate the ease with which Collector can suck down any CID, store it locally on a device, and persist it to WNFS.
• Ignite a bit of a competitive treasure hunt

Rationale

What does this demonstrate about ODD?

How does this support hackathon participants?

How do we measure success?
80% of installs download at least 1 presentation.

Details

• Contract for logging the collection actions
• What file formats to support?
• Should probably monitor network stability / speed, grab a poster frame, and download the rest in the background

ETA: 2023-11-11

Related Issues

Let's prep this repo to become public. Some preliminary steps:

• Write a readme/documentation
• Add issue templates
• Solve as many of the integration issues with @odd/ts-odd#next as possible(various polyfills/externalizing packages)
  • Get basic auth flow working
  • Possibly make a storage library based around expo-secure-store

ETA: 2023-11-11

This needs much more specification and discussion, and should be built with a separate budget, possibly with a separate team.

Goals

Core: Demonstrate Collector interacting with an FEVM contract, within a sandboxed environment (ie. embedded web view)

Stretch: Also allow interaction on a desktop browser via WalletConnect, which would require implementation of EIP-5630 to ensure the user’s

Rationale

What does this demonstrate about ODD?

1. (stretch) The safe but portable nature of ODD derived encrypted data.

How does this support hackathon participants?

1. Fund Ring itself provides a potential source of crowd funding.
2. Example of how to have the native FIL account connect to a dapp.
3. Example of a message signing flow
4. (stretch) Example of FIL-native WalletConnect flow
5. (stretch) Session keys?

How do we measure success?
50% (?) of IPFS Connect attendees participate in funds distribution.

Details

• certain amount of FIL held in escrow
• when you finish qualifying (eg. swap w/ 50 people, archive 10 presentations, etc) you can spend a portion of the locked FIL on any Fund Ring compliant contract

ETA: 2023-11-11

Related Issues

Goals

Core: Grow installs of the app via the vCard Exchange share code.

Rationale

What does this demonstrate about ODD?
?

How does this support hackathon participants?

1. Demonstrates and app growth tactic

How do we measure success?
Percentage (50%?) of people who, after scanning a vCard QR Code, make it all the way to creating a FIL account. The funnel is:

• Scans QR Code
• Lands at test-flight installation
• Installs testflight app
• (probably) Scans QR Code a second time
• Connection is made

Details

• When a person shares their contact,
  • if the recipient doesn’t yet have Collector installed, the link will prompt them to join the Testflight
  • if the recipient does have Collector installed, the link will add the vCard to their contacts

ETA: 2023-11-11

Related Issues

Goals

Goal: Update iOS build to work on Android with full feature parity

Rationale

What does this demonstrate about ODD?

1. Cross-platform support

How does this support hackathon participants?

1. A cross-platform codebase to launch projects from
2. If using Collector as a dev wallet, a cross-platform FIL native wallet client

How do we measure success?
All iOS tests pass on Android as well.

Details

Related Issues

Goals

Goal: Let people exchange contact info that includes wallet address info, and demonstrate where that fits in a vCard

Stretch: Use WalletConnect V2 messaging to subscribe to vCard updates from that associated address - and then request it via the same channel?

Rationale

What does this demonstrate about ODD?

1. (If we implement it this way) Shows how ODD can be used in a wallet client to maintain a local copy of signed messages and transaction history (in this case, of exchange events logged in the contract)

How does this support hackathon participants?

1. Creates a rich onchain data set to query
2. Provides an example of FIL native account interacting w/ a contract
3. Provides an example of how ODD/WNFS can be used to securely keep a user-owned backup onchain and offchain message history

How do we measure success?
60% of installs exchange vCards with at least 3 other people.

Details

• When two people speak the event and would like to stay in touch
  • As one of the conversation participants, I want to exchange vCard info with them, so we know how to contact each other after the event.
    • QR Code scan mode
    • NFC tap mode
  • As the ODD team, we’d like that to result in both people having the Collector app, so that we get a broader sample set.
  • As PL, when these folks exchange contacts,
• Keep a log of addresses met
  • Combined with your contacts data to make it human readable in the app without divulging any info publicly
• Simple leaderboard
• No PII needs to be stored on IPFS nor onchain
• Using Account Metadata standard extension for addresses? https://docs.google.com/document/d/1baSoCMcd8LHsOcg_KKLJLBqhqBreI2A6KldD9l86jC0/edit#heading=h.mk41nv5erwgt
• How do we represent this in a standard vCard format?
  • https://github.com/DigitalArsenal/vcard-cryptoperson
• How does this get ingested into the Contacts app?

ETA: 2023-11-11

Related Issues

Since we don't have access to indexed db in a native mobile context, we will need to implement a custom storage component for collector.

It seems like the best method here may be to create a localforage driver that uses expo secure store

ETA: 2023-11-11

Goals

Core: De-risk Testflight deployments and ensure that there is a fast means of getting new builds to everyone on the team.

Stretch: Distribution of APKs to Android devices via the same build step. Idea here is once again to just explore getting the build pipeline working — not to maintain.

Rationale

What does this demonstrate about ODD?
That it works in a native mobile context!

How does this support hackathon participants?
Provides a re-usable ODD/WNFS library that works on native mobile.

How do we measure success?
All members of the Electron Pod with iOS devices have successfully installed the build via Testflight

Details

• This will allow all test populations (with iOS) to easily participate in testing throughout further sprints. Initially, this will be Electric Pod, but I’m sure other folks w/in Fission will be interested. And eventually we’ll likely want to add some other PL / Filecoin Foundation stakeholders.
• Let’s ensure that we are all refamiliarized with Testflight ops:
  • Issue reporting
  • Crash logs
  • Analytics
  • Sync to GH issues

ETA: 2023-11-11

Related Issues

Goals

Core: Initialize a FIL Native (aka FVM F1) EOA within the React Native app, and use it to derive encryption keys to drive an ODD Account.

Stretch: Try an Android build. This will be the last story in which we quickly see what kind of Android parity we get for free. We’ll only test Android for FIL account creation, not backup and recovery.

Rationale

What does this demonstrate about ODD?

1. That we can reliably and deterministically create WNFS key material from FIL key material.

How does this support hackathon participants?

1. Preparation for more fully featured FIL native accounts in a native mobile wallet.
2. Reusable code for powering other FIL native mobile wallets.

How do we measure success?
Able to send & receive FIL via the account in Collector. Sending and receiving FIL via Collector likely will not be a user facing action at the outset, but this seems like the best way to double check the validity of the EOA.

Details

• We should clarify the threat model:
  • Propose this follow the pattern of Farcaster, where this is encrypted and backed up to iCloud, but is largely non-exportable.
  • At the UX level, there will be no account recovery flow.
  • At the code level, we need recovery on a device where the app is re-installed and the private key is retrieved from iCloud.

ETA: 2023-11-11

Related Issues

Goals

Core: Have a respected 3rd party auditor attest to the security of code and approaches used.

Rationale

What does this demonstrate about ODD?

1. That it meets a security standard

How does this support hackathon participants?
2. A forkable codebase that meets a security standard

How do we measure success?
Pass the audit.

Details

Related Issues

Goals

Core: Enable easy switching between testnets and mainnets, both FVM and FEVM.

Stretch: Add any other features that may ease the speed of debugging and development, such as the addition of custom network + RPC endpoint in the instance where you are developing against a local instance of an FVM/FEVM testnet.

Rationale

What does this demonstrate about ODD?
Nothing.

How does this support hackathon participants?
Most hackathon development occurs on testnets, local or remote.

How do we measure success?
Members of our team are able to switch back and forth between testnets and mainnets without issue.

Details

• There should be an ability to toggle the app into dev mode in a settings view. During this early builds that toggle will be enabled by default.
• Dev Mode should be clearly indicated in the UI, in preparation for future builds where it may be disabled by default and will impact the behaviour of the app.

Related Issues