BerryTree

Status

BerryTree has been unpublished from Google Play, and its server has been unreachable since roughly August 2026. There was never an iOS release. There is no project website; the Discord server linked above is the only official presence we have been able to find, and at time of writing it is locked with a notice that the service is down.

This entry exists because BerryTree users are holding export files from an app they can no longer run, and the recovery question is a real one.

Evidence level

This entry draws on two sources, neither reviewed or confirmed by anyone from the project, which is why it is not marked self-reported:

• A single export file, contributed by a BerryTree user. It was generated from a test account, so only seven sections held records.
• Static analysis of the last public Android client (1.0.16), carried out for interoperability. This shows how the app reads and writes each kind of record through its server API, which covers most of the sections the export sample left empty.

The two are not equally strong, and the record shapes below say which one each comes from. "Seen in export" means the field names were observed in a real export file. "Inferred from client" means the shape is what the app sends to and reads from its server; the export is a dump made on the server side, so its field names are very likely the same, but that has not been observed.

They can differ. The export sample carries fields that the 1.0.16 client never references at all, such as status_label on front entries and layer_ids, system_context_ids and hidden_in_contexts on members. So the server's data model had moved ahead of that client, and a real export may hold fields the client analysis cannot describe.

Corrections are very welcome, particularly a populated export.

Export shape

A single JSON document, produced by the server and saved unchanged by the app. Top-level keys observed:

app, schema_version, exported_at, system, members, front_entries, custom_statuses, chat, polls, reminders, privacy_buckets, useful_links, folders, sub_systems, notes, journal, relationships, places, map_nodes, field_templates, user_settings, external_contacts, external_relationships, cross_system_relationships, system_contexts, layers, _partial_errors.

The sample carried schema_version: 3.

Details worth knowing before writing a reader:

• custom_statuses holds two different things, discriminated by kind. Rows with kind: "type" are fronting types that annotate a front entry. Rows with kind: "status" are standalone fronting entities that front with no member attached, which is the custom-front pattern. Treating them as one list produces a roster full of things that are not members. A missing kind means "status".
• The system profile is not on the system object. That one carries little more than a username and an account email. In the sample, the name, description, avatar, colour, tag and pronouns live on the system_contexts row whose kind is "main". The 1.0.16 client, however, never references system contexts, and edits the profile through these user_settings keys instead: system_description, system_avatar, system_banner, system_tags, system_custom_fields and system_status. A reader should check both places.
• _partial_errors is the exporter's own failure log. A file carrying entries here was already incomplete when it was written, and a reader should surface that rather than presenting a clean import. Note that these strings are written by the exporter about a record that failed, so they can quote user content; treat them accordingly if your job logs are not encrypted.
• Images are references, not bytes. An avatar, banner, folder image or profile-block image is either a base64 data:image/... URI, which is self-contained and survives the server being gone, or a URL into public object storage, which only works for as long as that storage keeps serving. URLs pointing at the app's own server are dead.

Record shapes

Timestamps are ISO 8601 strings. Records carry a string id, and the export sample shows a user_id owner field on every record type it had.

• members[] (seen in export): name, display_name, pronouns, role, description, color, emoji, avatar, banner, is_private, proxy_tags ({prefix, suffix} pairs), custom_fields, tags, folder_ids plus a legacy single folder_id, sub_system_ids plus a legacy single sub_system_id, pinned, is_template, archived (a flag with no date), counts_toward_headcount (defaults to true), hide_from_main, mood (free text), blocks, theme_overrides, and server-set short_id, thumbnails and has_avatar/has_banner flags. tags is a plain list of strings (inferred from client; empty in the sample).
• members[].custom_fields[] (inferred from client): one object per field, {label, value, type, template_id}, matched to its template by template_id or, failing that, by label ignoring case. value is always a string. A friend_note field instead holds entries, each with a body, a timestamp and the name of the friend who wrote it, which makes that content another user's writing.
• members[].blocks[] (inferred from client): profile layout blocks of type paragraph, h1 to h3, quote, list, image, gallery, divider and columns. The inside of a columns block is not known.
• field_templates[] (inferred from client): label, type, required, order. The types are text, longtext, markdown, html, block, color, date, url, number and friend_note.
• front_entries[] (seen in export): member_id, custom_status_id, fronting_type_id, note, custom_status (free text), status_label, started_at, ended_at (null while still fronting). A sub-system fronting as a unit is stored as one entry per member tagged with subsystem_id (spelled without the underscore here, inferred from client). Legacy form: older data records a fronting type as member_id plus a custom_status_id that points at a kind: "type" status, and sometimes as a custom_status_id of that kind with no member at all. Entries can also point at a status that has since been deleted.
• custom_statuses[] (seen in export): name, emoji, color, description, image_url, kind, category, sort_order. The five default fronting types are created by the server.
• folders[] (seen in export): name, color, emoji, description, image, is_private, parent_id, show_in_main_list, sub_system_id.
• sub_systems[] (inferred from client): name, description, emoji, color, avatar, banner, pronouns, tag, leader_id, is_private, can_front_as_unit, hide_members_from_main, custom_fields ({label, value} pairs) and member_ids. Membership is also recorded on each member, so a reader should combine both.
• journal[] (inferred from client): title, body (Markdown), mood (free text), member_ids (several authors, with a legacy single member_id), tag_ids, folder_id, created_at.
• notes[] (inferred from client): title, body (plain text), color.
• polls[] (inferred from client): question and options, each option being {text, votes} where votes lists the ids of the members who chose it.
• reminders[] (inferred from client): title, time as HH:MM, days as a list of mon to sun, and enabled.
• useful_links[] (inferred from client): title, url, description.
• chat[] (inferred from client): channel_id, member_id (the member posting) and text (Markdown). The client shows no replies, reactions, attachments or timestamps.
• relationships[] (inferred from client): member_a_id, member_b_id, type_id, type (a copy of the type's label), note, and optional per-link styling. Reciprocal relationships are stored as two rows, one in each direction, linked by inverse_pair_id, so a reader that does not deduplicate on it imports every such link twice. Older rows can have a type label and no type_id.
• external_contacts[] (inferred from client): name, role, pronouns, emoji, color, description. No avatar.
• external_relationships[] (inferred from client): member_id, external_contact_id, type, type_id, note.
• cross_system_relationships[] (inferred from client): member_id, friend_user_id, friend_member_id, type, type_id, note. The friend ids point at another account on the same server, so they cannot be resolved anywhere else.
• privacy_buckets[] (inferred from client): name, color, member_ids, friend_ids, allowed_features, field_template_ids.
• places[] (inferred from client): name, description, color, icon, parent_place_id (places nest), map_id, member_ids, images, and a position as x and y.
• map_nodes[] (inferred from client): member positions on the relationships graph, with no content of their own.

Not in the export

The app has several features whose records have no section in the schema_version: 3 export. They were either not exported or added after that version, and only a newer export would tell which:

• Journal tags and journal folders, which the journal entries refer to by id.
• Chat channels and categories, which the chat messages refer to by id.
• Relationship types, including their colours, symbols and whether they are reciprocal.
• Mood check-ins and dissociation self-assessment (DES) results.
• Named maps, the connections drawn between places, and free-form canvas items on the map.
• Habits and habit logs, custom quiz questions, and a companion pet.
• Friends, friend requests, and notes shared with a friend.

Known loss

Things BerryTree tracks that have no obvious v0.1 target:

• Fronting types as a first-class user-editable vocabulary attached per front entry.
• Multi-context rosters with layers, including per-context member hiding (hidden_in_contexts).
• Inner-world map (places, map_nodes).
• Named privacy buckets.
• External and cross-system relationships, as distinct from member-to-member ones.
• Member templates as a first-class flag.
• Per-system useful-links list.
• Profile blocks, as a structured layout rather than a description.
• Assorted per-member flags: silent_switch, hide_from_main, pinned, short_id, theme_overrides.

How to get an export

The export is generated by BerryTree's server: the app requests it and saves the reply as a JSON file. With the server unreachable, no new exports can be made, so the only exports that exist are ones users saved while it was running.

The app also keeps a local cache of the server responses for screens a user visited, stored in its private app storage. On a device where the app is still installed that cache may hold data that was never exported, but reading it requires root access to the device.

Reader implementations

Sheaf ships an importer covering the system profile, members, custom statuses, fronting history and folders, marked experimental for exactly the reason set out under Evidence level. It counts and reports every section it cannot read rather than guessing at field names, so an import tells the user what was left behind instead of quietly dropping it.

The PluralPort Converter reads the same export in the browser and writes a PluralPort file covering members, custom fronts, folders, tags, custom fields, front history and images, for apps that do not have a BerryTree importer of their own.