To improve and simplify the ability for clients to construct threads from batches, we could make a single Parquet schema that can include all the content-related announcement types (think of each Parquet row as being a union of the fields in Broadcast, Reply, Reaction, Update, etc.) — many of these fields are overlapping anyway). Rather than posting separate batches for each of those types we get more efficient use of blockspace. Clients need to change the way they process the batch but IMO this will make thread construction and maintenance more efficient than less.
Pros:
- For batch creators, fewer batches (and therefore on-chain transactions) represent
- For batch consumers, fewer batches to consume
Cons:
- Somewhat more complex schema parsing
- Arguably less expressive schemas (as many columns would be declared optional
- Small increase to bytes per row
Open questions:
- Which Announcement Types would logically be grouped by this approach?
- Dealing with legacy data?
To improve and simplify the ability for clients to construct threads from batches, we could make a single Parquet schema that can include all the content-related announcement types (think of each Parquet row as being a union of the fields in Broadcast, Reply, Reaction, Update, etc.) — many of these fields are overlapping anyway). Rather than posting separate batches for each of those types we get more efficient use of blockspace. Clients need to change the way they process the batch but IMO this will make thread construction and maintenance more efficient than less.
Pros:
Cons:
Open questions: