@tess @smallcircles @cheddarcrisp granted both of those two features are more focused on privacy (which puts authors/posters in control) than information overload/segmentation, for which we’re thinking about another approach (which puts readers/followers in control): https://github.com/bonfire-networks/bonfire-app/issues/646

@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

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 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