I love this idea, sadly there doesn't seem to be a in-magazine search yet. The global search icon on top menu bar does seem to work pretty well and adding the magazine name + space + search query did seem to work somewhat.
Kbin is very young, so the documentation is lacking basically everywhere. The developer, ernest, was scrambling this weekend to get some of the docs around setting up a server in shape for tomorrow, and desperately trying to keep k-soc's hamster alive as the instance went from a few dozen to several thousand active users.
Ultimately, despite its level of polish, it's not production level software, and we're all just making due.
The project is open source, though, and there's nothing stopping anyone from making mobile apps are alternative web front-ends. By the end of this week, there will likely be dozens of servers running kbin, if not hundreds, and whether they want to allow external actors to use the API will be up to each server's administrator.
But anyone thinking about it should be aware that ernest was contemplating making the kbin API Lemmy-like, as Lemmy has a significant head start on number of sites running it, and until very recently number of active users. But given the explosion in attention kbin has gotten, and the explosion in population on k-soc, that might not be a priority any longer.
In order for anyone to build new clients, the API first needs to be finished. Unfortunately, the choice of using PHP/Symfony is going to hinder that due to its incredibly low popularity. I got my start in software engineering by professionally writing PHP, but I haven't touched it in at least 15 years.
I'm currently trying to find my way around kbin-core, and it is a mess. There are almost no comments (and some commented-out code with no explanation), huge amounts of what I assume are stubs, and the commit log is a nightmare (commit descriptions are meaningless and repeated, like four commits in a row with only "Post expand fix" as a description).
This needs a lot of work before anyone should start trying to build API integrations.
Is that because of the DDoS protections currently up on k-soc, or is that a more fundamental issue? Because AFAIK, which isn't a whole lot kind you, the front end is using the API
I probably don't know all that much more than you, but I don't think you need an API when you both control the frontend and backend, they can just talk to each other directly.
An API is useful when you want to give out data to third parties, so they can make their apps/services/whatever work without being able to directly access the internals of the software.
They directly talk to each other via an API. Even if you own all layers of an application like this (e.g., presentation layer, front-end APIs, back-end, etc.), each layer communicates via APIs. These may be private APIs that third parties cannot use, but they are still APIs. Even if it looks much different from the usual RESTful HTTP APIs we're used to, any other solution would still be considered an API.
The errors from the API are because the API is not written. The routes (URLs) are defined, and some of them have a little code to generate responses, but the code is simply unfinished and does not yet work.
AFAIK, which isn't a whole lot kind you, the front end is using the API
The web UI is mostly generated server-side. Even user preferences are set by navigating to a URL rather than having some XHR/AJAX/etc. request handle it. This is still a sort of "API" but most of what is traditionally done by client-side JavaScript is handled within a monolithic PHP application.
So, no, the current web UI is not using the API in any sense you would expect.
I am in the same boat as you. I’m an experienced software engineer and I’d like to help this platform grow, but I lost a lot of enthusiasm once I started looking through the core codebase..
Oh man, that doesn't sound ideal.
But kbin has a lot of momentum at the moment with a lot of people possibly willing to support it and some cool concepts, so I really hope there's a chance to make this fly.
So where do you think kbin's best odds lie at the moment? Clone and rewrite it in a different language while it's still early or work with what's there? Get a couple of iterested devs together to do some brainstorming?
There's always the option of lemmy of course, which is written in Rust I think which certainly has a lot of fans, but personally as mostly a user I like kbins approach better in a lots of ways and I would find it hard to actively support and participate in a project from open tankies.
I think regardless of personal views, the project is essentially tainted and should be avoided. Too many users will feel alienated by the controversy. I came to kbin because the lack of such controversy points to better viability for such a large community.
So where do you think kbin's best odds lie at the moment? Clone and rewrite it in a different language while it's still early or work with what's there? Get a couple of iterested devs together to do some brainstorming?
Rewriting it in a different language/framework was my first thought. Honestly, though, it is pretty large and I don't think I have the amount of time I would want to contribute to such a project. I might still make an attempt, but I agree that the best bet is to have a number of dedicated volunteers get together, plan something out, and execute as a team.
I also have real concerns about the architecture that was chosen. It is going to be really hard to scale this without just throwing a ton of money at it to horizontally scale [edit: or vertically scale, right now, since this doesn't seem to be ready for any kind of clustering] the entire app at once. It's just being operated as a single docker container running on a single VPS. This is just asking for trouble. The ecosystem with which it needs to integrate is mature enough that some reasonable optimizations can be made to keep performance good, especially around the federation APIs, clustering, and other separation of concerns.
I think regardless of personal views, the project is essentially tainted and should be avoided.
There's of course also the option to simply fork lemmy's current codebase and try to turn it into its separate thing from there. But that might come with its own caveats and the potential to become a fairly messy affair.
In general I like the idea. My only suggestion as a caveat is that whenever possible we offer non-corporate alternative URLs instead of the types of sites the fediverse is trying to improve upon.
For example, post Invidious links instead of YouTube, Nitter links instead of Twitter, and just about any link you can think of instead of Google or Facebook.
I disagree with this. I'm all for federated and non-corporate alternatives but I think we should post the source and not an alternative front-end. Those that want to use exclusively those alternative front-ends have access to browser add-ons that automatically redirect them.
No worries. I said “whenever possible” because I know it’s a lot to ask when people aren’t used to federated sites.
As for me, I’ll always convert Corp sites to federated ones and I’ll always post links to what I consider to be more ethical sites, but of course anyone’s free to do what works for them.
Maybe have a bot that posts a nitter.net equivalent as a top-level comment when someone posts a Twitter link? Hell, post a screenshot too, if you want.
I disagree with this opinion. Has your opinion changed with YouTube’s stand on adblocking? What about with Twitter’s post limiting? (Are you sure you’re in the right place?)
why? what's wrong with the alternative? as long as the origine of the source is clear, meaning the person behind it, I don't see the problem. could you elaborate if you would?
Absolutely nothing wrong with the alternative front-end in itself. In my mind it should just not be used as the direct link, just like the screenshot shouldn't be used.
However, someone linking to the alternatives in the comments for convenience is a good idea.
In Mastodon, it is very simple to migrate from one instance to another. You retain your followers, those you follow, and your messages.
It is something essential in a community that is growing so rapidly and can overwhelm any instance with limited resources.
In /kbin, we are experiencing the same thing these days with the #Redditmigration. There aren't many instances yet, but we could help a lot if it were easier to migrate to another instance with less traffic than .social.
Not sure about JS, but from some cursory experimentation there don't seem to be any limitations on what can be done with the custom CSS. It seems to just load whatever CSS code you put there into a style block at the top of the finalized page source, so anything goes really. I wouldn't be surprised to see limitations on this in the future since this could obviously lead to some annoyances from making the entire page invisible to overlaying a seizure gif onto everything.
As far as documentation I don't know of anything official, but /m/kbinStyles seems like your best bet for asking questions, alongside using inspect element to identify the elements you want to style while consulting a CSS reference like w3schools. Also iirc, browser extensions like Stylus let you create custom themes for sites while previewing them on the fly which would be pretty helpful here. As long as you're not trying to do anything crazy complex you could probably learn what you need to style a magazine in an afternoon!
Thanks for the reply, I tried asking there but any CSS I put in the box seems to just be ignored :( Did you manage to get it working? I only managed to change the background, but trying to change vote colors didn't work.
I took a look at the code snippet you posted in that thread and it works when I apply it to my magazine, although it looks like the kbin-it theme overrides the vote colors, so if you happen to be using that or some other theme you'll have to slap on an !important tag to force it to use your colors. Like so:
Also, from reading over that thread, you mention that both the vote icons still appear white for you, do you mean for the colors to apply to votes that haven't been clicked on too? If so just removing ".active" from both of the style blocks should do the trick. As-is the color will only show if you actually click upvote or downvote, otherwise they'll both be white.
Oh brilliant, you're absolutely right, I just didn't realize that it only affected the activated button's color. Good to know! Do you know if you can change the icon from an arrow to something else too?
Keep in mind this'll only appear correct if the icons you use are all black in color, since it applies a filter on top of them to get to the correct color for active/inactive. To get around that you could make two sets of up/downvote icons with the appropriate coloring, one for active and one for inactive - just remove all the lines that say 'filter' and in the bottom two style blocks put background-image: url(link to your active up/downvote icon); instead.
I just enabled it after you said this. I'm not sure I like how it sticks to the top when scrolling... but it does make it easier to switch between all/subscribed. I'm guessing the magazines it lists along the top are just the recently created ones?
I'm almost certain of that because I'm not subbed to the majority of the stuff it has. Anybody who has enabled NSFW content, don't browse with the top bar on in a SFW location, mine is currently showing NSFW items.
Agree, it makes navigation a lot more intuitive. In terms of settings that could be made default, perhaps turn on reply notification as a default as well.
/kbin
Oldest