ivan

Hi! 👀

here an attempt of an improved UI for boundaries, the main outcomes are:

• Reduce the permissions list toshow only the relevant ones for each activity type (eg. see / read / like / boost / mention / reply / edit (future one) / delete (future one) ...)
• Default the permissions to be the same for all the users/circles involved
• Let the user expand each verb to customise the permissions for the users involved (fig.3)
• replace the 3 icons that shows the permission states (can / undefined / cannot) with a more standard 3-toggle state

Might be my lack of understanding, but I'm assuming that by defining a 'circle' I'm adding a group of people to a list.

This is different to creating a 'boundary' where I'm defining permissions of the people in that list in relation to my posts.

Is that right? At the moment, I feel like the circle/boundary language could be clearer?

I think it makes a big difference that the topic "acts" like a regular "user" account but is stewarded by potentially many users. Why don't you just name this "channels"?

I have a suggestion for Bonfire:

@BonfireBuilders #bonfire_feedback

+Tropic_the_Topic

It seems strange that the topic view doesn't displays nested comments.

What is a topic, a more "stable" place for discussion and moderation (which would benefit from nesting), a collection of things that belong together (more like tags), or an automated user (as topics are "boosting" posts)??

If you're not logged in, you have the option of leaving a comment, but it doesn't work. Pressing "Send" in the comment box results in a message that says "There was an error." There was no mention of what the problem was, but I'm guessing it's because I wasn't not logged in.

If you are logged in, you can comment without a problem.

There are a lot of teething issues with Penpot at the moment and I found it slower to work in than Figma. I've been keeping an eye on the project and I provide feedback to the team, and I hope it continues to improve. But right now, I wouldn't recommend it for use in production unless you're willing to make some time to log the bugs and problems you encounter along the way.

I imagine that lots of Fediverse projects require some technical knowledge to set up. Even something relatively straightforward like "Go to Mastohost's website and pay for a hosting plan" might seem easy to someone with experience, but overwhelming for someone who doesn't know what they're doing.

It would be brilliant to work on removing that technical skills barrier in the open and create a new source of revenue for the projects. That's a great idea 🙌 if there's anything more I can help with, I'd love to be involved.

There might be concerns around having only 1 private company hosting the majority of instances for a platform, e.g. what happens if the platform gets very popular and an investor buys the biggest hosting company of that platform? It would be worth thinking about how we tackle that as well.

In terms of moving the design system to Penpot, I should let you know that you can share a prototype publicy like I did, but you can't share the actual design file publicy. You can only invite others to join via email - there's no option to share a view-only link or anything like that, which you have in Figma. So I think it would be harder for other designers to access Bonfire's design work if you move it into Penpot at this time.

Hey @ivan

I've been thinking a lot about how we could make federated social networks more accessible for people who:

• Don't want to learn how to set up hosting or use the terminal.
• Have a limited knowledge of instances, federation, and all the technical workings of the Fediverse.
• Want an online space for their community which isn't Facebook.

I know you mentioned it's something your team's been considering a lot as well.

I wanted to wireframe a Bonfire setup process which doesn't require any technical knowledge. No finding a hosting provider, and no using a terminal. I also wanted to experiment with concepts which users would be familiar with from other digital products, like "trial" and "upgrade," by offering hosting as a service which can be bought and managed within Bonfire.

My idea is that users can set up a test instance on a Bonfire-hosted server as a "free trial," with a limit on the resources which this instance can use. Once they have tried out Bonfire's features and customised their instance to suit their needs, they can then pay for a hosting plan with a partner company. Their instance's data is then transferred from the Bonfire-hosted server to the partner company's server, and any appropriate DNS records are set up automatically (either for the subdomain.bonfire.cafe address, or for their own custom domain).

Here's my prototype:

design.penpot.app/#/view/27a...

What do you think of the idea?

I have a suggestion for Bonfire:

@BonfireBuilders #bonfire_feedback

When going to the Messages section, there is a weird drop down menu appearing that says "My feed". It would be better to just leave the navigation list and highlight Messages instead of changing the mode of navigation suddenly. It looks like I'd be sending a message to my feed if I'd push the "New message" button.

I have a suggestion for Bonfire: while I'm all for experimenting with the UI, having eight different menu options together is... a lot!

Notifications, message, and favourites are qualitatively different, I would suggest, from feeds (my, local, federated). I'd expect to access settings and the ability to logout from my profile, perhaps? 😀

@BonfireBuilders #bonfire_feedback

I have a suggestion for Bonfire:

@BonfireBuilders #bonfire_feedback

• The current playground instance is very slow for me, which maybe highlights some issues in the user interface quite nicely.
• After hitting the "post" button, input fields remain editable
• When having trouble uploading images I don't know if it is due to the server timing out or another problem.
• Creating circles and boundaries seems quite important to Bonfire but are very hard to try out because
• these options are only accessible via settings, which takes a long time to navigate to, and when I'm there I'm missing the context of the posts that would help me make decisions. I would want to put somebody in my "arch enemies" circle based on some post they wrote, but I cannot see any posts deep in the settings.
• it is possible to create new boundaries on the fly, just before posting, but from that minimal view you're missing the list of boundaries you already created and in general don't have the full view of what this is doing.
• Applied boundaries are designed to like "tags" that can be arbitrarily combined, but they are not in fact. The first "tag", which defaults to "Public" should not have a closing ×, because it makes no sense to delete it. Every post hast to be Public, Local, or only visible for mentioned users. So it should be a dropdown menu. Following boundaries might well be tags, but I don't understand how combining multiple boundaries would work. So if I add somebody to "work contacts" and "arch enemies" and in one boundary that user can read and not in the other, what will happen? How can I get an overview of who will be able to see and interact with the post? At least the users with conflicts should maybe be listed somehow?

I have a suggestion for Bonfire:

@BonfireBuilders #bonfire_feedback

• The current playground instance is very slow for me, which maybe highlights some issues in the user interface quite nicely.
• After hitting the "post" button, input fields remain editable
• When having trouble uploading images I don't know if it is due to the server timing out or another problem.
• Creating circles and boundaries seems quite important to Bonfire but are very hard to try out because
• these options are only accessible via settings, which takes a long time to navigate to, and when I'm there I'm missing the context of the posts that would help me make decisions. I would want to put somebody in my "arch enemies" circle based on some post they wrote, but I cannot see any posts deep in the settings.
• it is possible to create new boundaries on the fly, just before posting, but from that minimal view you're missing the list of boundaries you already created and in general don't have the full view of what this is doing.
• Applied boundaries are designed to like "tags" that can be arbitrarily combined, but they are not in fact. The first "tag", which defaults to "Public" should not have a closing ×, because it makes no sense to delete it. Every post hast to be Public, Local, or only visible for mentioned users. So it should be a dropdown menu. Following boundaries might well be tags, but I don't understand how combining multiple boundaries would work. So if I add somebody to "work contacts" and "arch enemies" and in one boundary that user can read and not in the other, what will happen? How can I get an overview of who will be able to see and interact with the post? At least the users with conflicts should maybe be listed somehow?

I have a suggestion for Bonfire:

@BonfireBuilders #bonfire_feedback

When adding several images to a post and the describing them, the images might be cropped in a way that makes it impossible to understand what description should fit to what image if they are too similar. The example below is about a user interface detail in two different states. The important differences are not visible on the crop.

In general, preview images should not be cropped but scaled down, and users should have a chance to look at a bigger-size version of these previews to verify these are the actual images they intended to share.

Every definition of "entrepreneur" I can find involves an (heroic) individual... but I don't want the future of co-operativism to depend in any way on that sort of romantic individualism.

I want co-operatives to, instead, develop collective modes of deliberation and consensus building, with as little institutionalization of power structures and as little reliance on charismatic personalities as possible.