# BDS - 1st Community Call

* Date: Monday, April 14 · 4:00 – 5:00pm CET
* Meeting recording: https://drive.google.com/file/d/1HiufFNfioWFxklAdrnzxLw5UwFZSTTRQ/view
* Meeting transcript: https://docs.google.com/document/d/1OkedtX3O6gnI8KOWVv_ktIOn7z9jbwkq6NFYBZ0_Hz0/view
* Meeting chat: https://docs.google.com/document/d/1OkedtX3O6gnI8KOWVv_ktIOn7z9jbwkq6NFYBZ0_Hz0/view

## Agenda
- Interested participants introduce themselves (Name, Company, Expertise)
- Discuss the main scope, goals, governance and activities of the working group
- Review the https://github.com/blockchain-data-standards/manifesto structure, request/response, and content
- Define the first over-arching milestone to hit (think a 3-4 month end result we want to see)
- Suggestion:
- Create a registry of schemas (in .protof, or Arrow definitions, or something more agnostic) for most common EVM entities.
- Develop and publish type/schema/util libraries for publisher and consumers of BDS-compatible data.
- Stretch Goal: Develop translation layers for one or two most common use-cases (Blockchain -> Postgres, and Blockchain -> Subgraph) with the end goal of faster speed and higher throughput + BDS compatible, meaning data providers can be hot-swapped.
- Define community and/or technical action items for next few weeks
- Suggestion:
- Iterate over repository structure of the schema registry (tools, formats, hierarchy)
- Add some basic entities end-to-end to gather community feedback (e.g. Evm Blocks, Evm Transactions and Evm Events)

## Meeting Highlights

1. Emphasize the difference between dApp Query/Filtering vs the data provider Querying/Filtering requirements.
1. dApps would store the data in their own DBs with purpose-built indexes, Data Providers mainly focus on large data loading and delivery.
2. For example Data Providers allow querying and filtering data only relevant to specific contracts and/or protocol (Uniswap).
3. dApps on the other hand create custom indexes and data structure and query engines for their own end user product use-cases.

2. It is useful of BDS offers design recommendations and best practices for Querying/Filtering as well to have similar experience when integrating different providers.

3. Most probably we'd need to have BDS Translation layer for a longer time until 3rd-party providers actually adopt the standards and recommendations.

## Action Items

1. Interested participants to create a base repository for common EVM Schemas and Entities. To explore best representation for the schemas: gRPC/Protobuf, OpenAPI, Arrow Schemas, Flatbuffers Specs, etc.
a. Express your interest in the Telegram group.

2. @Ozgur To experiment with different transport and serializaiton performance comparision (jsonl + gzip, protobuf + gzip, flatbuffers + arrow-ipc)