Show Posts
|
Pages: « 1 2 3 [4] 5 »
|
We are shooting for Alpha in August. Thanks for your patience.
|
|
|
This is in the works and already supported on the backend, but I think the interface will be designed and updated later.
Great to bring up and thanks for the mockup image!
|
|
|
Guys, first alpha release is scheduled for around August at the earliest.
|
|
|
The current software works well on mobile devices. Yes, the texts are difficult to read, but it only takes a bit of zooming action. I would hate to see the new software force me into mobile mode with drastically different formatting to the desktop version.
On Windows Phone, this forum's font sizes are a mess. Usernames are too small compared to the actual posts. Noted.
|
|
|
We have something especially great planned for this. Considering most of the non-techy world is switching to mobile devices and tablets, this will be a top priority. Thanks for the reminder!
|
|
|
Great feature. Seems like an easy add. Thanks for the link!
|
|
|
BBCode->code #include <gmp.h>
int main() { mpz_t num; mpz_init(num); mpz_fib_ui(num, 10000); gmp_printf("%Zd\n", num); return 0; }
|
|
|
Plugin engine is being worked on at the moment. Theming is part of this. The initial design will be available when we go through the ui/ux. The plugin engine itself holds to be higher priority at the moment. But we'll definitely have something for the public to see in the future.
|
|
|
EDIT: I mean the visibility of the animated gifs should be configurable by the admins and it shouldn't be an issue for it to be configurable.
|
|
|
How about trust ratings with an expiry date? Say, I'd like to flag someone's offer as not trustworthy. On the other hand, it's not like I would necessarily consider the person in question a serial scammer. An easy solution could be to give that person a negative trust rating for the next two weeks™, so that in effect the offer would come from a person with a trust warning. After some time, when the offer is no longer open, the negative trust is no longer required and thus could expire.
This is interesting. But instead of an expiry date, maybe decreasing as time passes? Reminds me of Gauntlet Legends life points in the arcade. (Pardon the reference for those of you who didn't play this game in the arcade.) We'll play with this idea and forum reputation will be in plugins so that developers can implement different plugins based on what they need.
|
|
|
Agree. This is definitely necessary. I can't believe SMF doesn't have this.
|
|
|
Will make this a priority in usability.
|
|
|
This would be awesome and I have personally thought about making the backend very similar to a SCM. However, this may take way more engineering than it's worth. We'll definitely think about this one carefully.
|
|
|
If you have good contributions maybe it's a possibility in the future. Because we have gone off-topic and features and things are starting to show up in different threads. Let's do that. Create a thread for suggestions or features.
This thread is closed.
|
|
|
You're right, but this repo is more than an API. It's misnamed because we were originally going to split things up more in multiple repositories. We decided we need to put this into a single repo instead for the following reasons:
1. Integration with the original forum requires some shim work that we did. You're totally right about not needing the data. And obviously our whole idea is to steal your data and sell it. (/sarcasm) 2. Supporting noscript is a big goal for us. Javascript in the browser isn't for everyone and I believe that information needs to be concise and not filled with unnecessary UI fluff.
This is my last response to you until you decide to be helpful and positive about the project. Before you insult our skills, take a look at our work and if you want to correct us in ANY way, please feel free to send over a pull request and we will evaluate it in a thread for EVERYONE to see and decide what's better. Open source means we are open to CONSTRUCTIVE criticism. Learn to contribute so that you can matter.
|
|
|
+1 Great idea. This is similar to how Facebook allows you to disable notifications for a thread you commented on. Will definitely pay close attention.
|
|
|
Everything going through GPG might be a possibility. I'd like to explore these options once we get the initial migration off the ground.
Although supporting the migration of this forum is the top priority, keep in mind that this is a separate product that's open sourced. We have a team that will funnel contributions from the public when the system becomes more stable.
|
|
|
Initial responses have been decent. I will be posting interesting posts to its own topic for further discussion after this week.
|
|
|
Users should have the option to upload a GPG public key that the forum uses to encrypt all notification emails.
Alternately or in addition to this, the forum should have native Bitmessage capability. This means letting users register with Bitmessage addresses and sending notifications through the Bitmessage network. Note that routing the notification through a honeypot gateway like bitmessage.ch doesn't count because the primary purpose of Bitmessage is to not have monitoring chokepoints with access to plaintext.
This is a toss-up. Technically we can enable the option without a problem and sensitive info like password reset links and things of the like can be sent with GPG if the users opt into it. What's the toss-up? I think the option to GPG encrypt all messages from the forum is a great idea. I agree, but it's more of a usability issue. I think users can and will get their GPG keys screwed up. We will try to put this feature in though. Just need to think about how to orchestrate it.
|
|
|
Users should have the option to upload a GPG public key that the forum uses to encrypt all notification emails.
Alternately or in addition to this, the forum should have native Bitmessage capability. This means letting users register with Bitmessage addresses and sending notifications through the Bitmessage network. Note that routing the notification through a honeypot gateway like bitmessage.ch doesn't count because the primary purpose of Bitmessage is to not have monitoring chokepoints with access to plaintext.
This is a toss-up. Technically we can enable the option without a problem and sensitive info like password reset links and things of the like can be sent with GPG if the users opt into it.
|
|
|
|