@spencer we’re working on the last few milestones towards 1.0 at the moment https://github.com/bonfire-networks/bonfire-app/milestones?direction=asc&sort=title&state=open and hope to have the RC1 (release candidate) ready soon, but the honest answer is “when it’s ready”

@tess @smallcircles @cheddarcrisp while protocol-level support would be ideal, both of these features can work fine (and have been implemented in Bonfire) without it:

- personas (multiple profiles per account) appear as separate users to everyone else, and can be followed individually

- when you address a post to a circle(s) it’s usually not a public post, so we basically bcc the circle members so their servers know who to show it to (similar to a group DM)

@smallcircles @tess @cheddarcrisp that's a different project, our website is at https://bonfirenetworks.org

@lawik @ex_06 I am considering adding a write buffer similar to this though, to batch DB operations when an instance is being hammered with incoming federation: https://github.com/plausible/analytics/blob/master/lib%2Fplausible%2Fingestion%2Fwrite_buffer.ex

@lawik @ex_06

We have DB-backed queues using https://github.com/sorentwo/oban to avoid dropped activities

@zabbeer@floss.social thanks 😊 @dynamic you may want to have a look also at https://bonfirenetworks.org/design

@triptych awesome! that sure sounds like the kind of projects we want to help build and support :)

@triptych As you wish! We already have “flavours” in the architecture with which you can package up the app with a set of extensions and configs (including app name/icon/etc).

@triptych great 😊 any question let us know!

To implement federation, all you need is to declare in your context what Activity and/or Object types you want to handle, eg for posts:
```
def federation_module,
do: [
"Note",
{"Create", "Note"},
{"Create", "Article"}
]
```

and implement these two functions:
- for outgoing: `ap_publish_activity(subject_struct, verb, object_struct)`
- for incoming: `ap_receive_activity(subject_struct, activity_json, object_json)`

@triptych

@triptych Example activity preview: https://github.com/bonfire-networks/bonfire_ui_social/blob/main/lib/components/activity/object/intent/intent_task_live.ex

“LiveHandlers” are simply a way to put a bunch of event handlers (handle_event, but also handle_params, etc) in a single module where they can be reused by multiple LiveViews and LiveComponents.

Examples: https://github.com/bonfire-networks/bonfire_ui_social/tree/main/lib/live_handlers

@triptych

2/2

- Schema: https://github.com/bonfire-networks/bonfire_pages/blob/main/lib/pages/page.ex
- Context: https://github.com/bonfire-networks/bonfire_pages/blob/main/lib/pages/pages.ex
- Create a page “act” (which along with “epics” is an optional way to define pipes that pass data between different extensions and modules in a particular order): https://github.com/bonfire-networks/bonfire_pages/blob/main/lib/pages/page.create.ex
- “Epic” definition (which reuses many “acts” from other extensions) https://github.com/bonfire-networks/bonfire_spark/blob/main/lib/runtime_config.ex#L120

@triptych

@triptych

A lot of choices about how to implement things depend of your data schemas, and how closely you want/can integrate with existing functionality. Eg. you could reuse PostContent if your data has a title/name, summary, and body. This is what we do for the WIP pages extensions: which means not much code needs to be rewritten
1/2

Example integration with the composer:
- form inputs: https://github.com/bonfire-networks/bonfire_pages/blob/main/lib/web/components/smart_inputs/create_page_live.ex & https://github.com/bonfire-networks/bonfire_pages/blob/main/lib/web/components/smart_inputs/create_page_live.sface
- include it in config: https://github.com/bonfire-networks/bonfire-app/blob/main/flavours/classic/config/bonfire_ui.exs#L118

@triptych

@triptych

- Incoming & outgoing federation (i.e. translation between ActivityStreams schema and your internal schema, the rest is handled out of the box)
- Integrate Boundaries

We don’t have guides written yet for many of these, but happy to point you to the relevant code (both the places to integrate with, and example implementations), some of which is documented.

2/2

@triptych yeah that just gets you a skeleton, then you’ll probably need at least:

- DB schema(s): https://doc.bonfirenetworks.org/database.html
- Backend logic modules (contexts)
- Integration with the composer (smart input)
- Publish activities to feeds
- “Activity previews” to display your custom activity and/or object types in feeds
- Custom UIs using https://surface-ui.org https://www.phoenixframework.org https://daisyui.com https://tailwindcss.com
- LiveHandlers as the glue between your backend logic and UI

1/2

@kyva hola, nuestros otros fondos vinieron de https://nlnet.nl/ y https://culturalfoundation.eu/stories/culture-of-solidarity-fund/

Learn how the Bonfire framework empowers communities to (re)design their digital spaces from the ground up: https://bonfirenetworks.org/design

@erikkemp @hirad

Yeah with Bonfire you could define different circles for that, which you could then block, or block partially: silence (not see anything from them) or ghost (avoid showing them your activities)