@bonfire@indieweb.social The latest release includes a way to switch between both modes while drafting a post, so you don't have to choose just one!
That's the same thing that happened to me! However, it's still going. Currently, whenever I click on one of my "active apps" (i.e. pages) it will tell me something like "this string is not found" or "you don't have permission to view this string". I wonder what happened. Also, I posted about this some months ago, with the #bonfire_feedback tag and non of the dev's have responded. Has anybody else gotten engagement from the devs?
#support tag maybe?
Still pumped for this project though.
@versolalto The pages extension is currently disabled because it is still in development (you should be getting an error saying that instead of the ones you got though, will look into that). Sorry you didn't get a response last time!
Yeah I see s3.nl-ams.scw.cloud on the list. Will open an issue on that repo.
There's also a merge request: gitlab.com/malware-filter/ph...
Hi gangsters, the Phishing URL Blocklist used by uBlock Origin seems to block our media cache server. You need to disable this block list temporarily in the uBlock Origin settings to be able to view images.
Go sack them at gitlab.com/malware-filter/ph...
(PSA, it's a joke, we're all in the same boat and sometimes automated filters have false positive, you don't collect 55,653 malicious domains by hand. These brave people are doing the State's job for free, something quite unusual in tech ˀ!)
Yeah I see s3.nl-ams.scw.cloud on the list. Will open an issue on that repo.
Hi, I'm checking out Bonfire! Good work here, what a wonderful UI.
@evanp welcome 🔥
@Oceane it shouldn't be up to us (as software builders), but up to each instance to decide if they want to have a limit and what number that should be. Currently the default is 2000 words (not characters!) but we can make that higher... From a technical point of view it can be useful to have some kind of limit (just like there is for filesize when uploading images) just to avoid slowing down the site or over-using resources, whether by accident or maliciously.
The limit is configurable in instance settings (see screenshot) and visible to people considering whether to join an instance on the about page: campground.bonfire.cafe/about
Excuse me, I've read in the local TL that there was a words limit on Bonfire now, but what are you trying to achieve exactly?
The Fediverse is confronted to all kinds of abuse and the only time post length has been a problem it's been fixed forever by the "show more" button. If you want to prevent the circular consumption of low-quality posts (which is something that I want too!) well… a meta discussion/feditips extension would feel more appropriate, for example as a sort of built-in, decentralized wiki that the microblogging composer would link to on first login
@Oceane it shouldn't be up to us (as software builders), but up to each instance to decide if they want to have a limit and what number that should be. Currently the default is 2000 words (not characters!) but we can make that higher... From a technical point of view it can be useful to have some kind of limit (just like there is for filesize when uploading images) just to avoid slowing down the site or over-using resources, whether by accident or maliciously.
@vera a link preview is supposed to appear, it wasn't in this case because of the absence of opengraph/oembed/etc tags, but that will be fixed in the next update
@vera testing if fixed: anagora.org/coop-cloud-feder...
@mayel @ivan Wow this was a tough one to find.
It's happening in the smaller post composer that pops up on the bottom right of the screen. Using a Mac, Google Chrome, 1700px or wider screen.
So for some reason when I reply, the Content Warning is being enabled by default. If I KEEP it enabled, then the space on this smaller posting window isn't being recalculated (minus content warning box space), and when I get to the end of the box, it runs over and I can't view what I'm typing.
So I had figured I had hit a "hard stop" and it wasn't allowing any further entry. I tried two different themes and it happened on both. Happened on three different themes, so no theme specific.
Removing the content warning option fixes the issue. Hope this helps. I've noticed some great speed improvements lately, by the way!
Attached video (maybe?). 😊
@ivan Here's some #bonfire_feedback if you haven't thought about this already. Have some pre-packaged sets of audience configurations - "Community Clubs", "Local Crises Support", "Family with Children", "Family with Teens", "Family Elder Care"
Also - how are you writing longer posts than I can? I keep running out of space. 😊
> When the computer takes more than 0.1 second but less than 1 second to respond to your input, it feels like the computer is causing the result to appear.
> This means that during 1-second response times, users retain the feeling of being in control of the interaction even though they notice that it's a 2-way interaction (between them and the computer). By contrast, with 0.1 second response times, users simply feel like they're doing something themselves.
> For web usability, this means that new pages must display within 1 second for users to feel like they're navigating freely; any slower and they feel held back by the computer and don't click as readily.
Arguably for something like liking or boosting it's not the same as an automatic UI interaction (like opening a menu, which should be as close to instant as possible), you're communicating with your instance's server and in turn other people's servers, but more importantly with other humans, since you're requiring attention from the author and/or your followers by taking that action.
So not "clicking as readily" as they say may be a pro?
@ivan @dajb another UI approach that could work is what some messenging apps do, where they have a slightly different icon to show various statuses: eg. message received by server -> message received by user's device -> message read. So in our case: click taken into account -> received by server -> queued for federation -> etc?
> When the computer takes more than 0.1 second but less than 1 second to respond to your input, it feels like the computer is causing the result to appear.
> This means that during 1-second response times, users retain the feeling of being in control of the interaction even though they notice that it's a 2-way interaction (between them and the computer). By contrast, with 0.1 second response times, users simply feel like they're doing something themselves.
> For web usability, this means that new pages must display within 1 second for users to feel like they're navigating freely; any slower and they feel held back by the computer and don't click as readily.
Arguably for something like liking or boosting it's not the same as an automatic UI interaction (like opening a menu, which should be as close to instant as possible), you're communicating with your instance's server and in turn other people's servers, but more importantly with other humans, since you're requiring attention from the author and/or your followers by taking that action.
So not "clicking as readily" as they say may be a pro?
#bonfire_feedback ^ no strikethrough?
@Oceane fixed 😊
Filed an issue: github.com/RobertDober/earma...
This has be fixed in the library, so should work with the next update.
#BonfireFeedback If you're going to truncate link urls grab page title and interpolate into status. Currently the length is too long to be "pretty" and too short to be useful.
@vera a link preview is supposed to appear, it wasn't in this case because of the absence of opengraph/oembed/etc tags, but that will be fixed in the next update
Any feedback on this?
github.com/bonfire-networks/...
@Oceane it seems that it works only
if the striked text is on a seperate line
The markdown processing library we use has a few bugs like this, we'll need to either compile a list and try to contribute fixes, or maybe use a different one.
Filed an issue: github.com/RobertDober/earma...