So let’s now draw up a rough outline of what this service discovery bundle would contain, so that we can follow their contents for the example users in our previous scenario.

The key information types are:

• Publication time and date of the bundle. This is used to indicate the beginning of validity of the contents of a bundle, so that a malicious user can't publish data that is “eternally valid”, and thus clutters up search results forever.
• A record for each community that a user has joined, and in which their service discovery bundle should be considered valid. These may have individual periods of validity, but always within the hard-limit of 7 days from the publication date of the bundle. Thus to remain in a community, the service discovery bundle has to be updated at least once per week. Again, this is to stop stale data clogging the network and search results. The maximum number of communities that can be listed in a bundle should be restricted to a relatively small number, perhaps 5.
• A record for each resource request, service request, resource offer or service offer, again with each entry having a validity period. These records should include both a textual description of the request or offer, as well allowing the specification of a number of emojis to provide a language independent description that can be used to support both low-literacy and through the use of an “emoji reader” vision impaired users. For low-literacy users it should be allowed to specify a request or offer that consists solely of the describing emojis. The emojis can also be used to provide a convenient visual description of a record for placement on a crowd-sourced map display. To support this, these records should also include a PlusCode location identifier, making it easy to draw maps containing this information.
• Records for the crowd-sourced mapping interface, that are not service or resource requests or offers, but rather situational-awareness markers, e.g., to indicate damaged roads or other infrastructure. These are otherwise similar to the request and offer records.

A data model with just these few record types are sufficient to support the various use-cases explored in the scenario in section 2. These will be fleshed out in a later milestone, once we have assured ourselves that they really are sufficient.