Consolidating Community Knowledge: Gauging Interest and Making it Happen

This is technical word porn for me and exactly what I was looking for to see how things have changed from the original White papers etc. Wonderfull.

More than enough to keep me occupied until testnet


This is a great initiative! :smiley:

Any plans to move away from using Auth0 development keys?

1 Like

Sorta :sweat_smile: In short, yes I want to do so soon, but if it turns out a lot of people are going to attempt to sign up for an account (>1000 or so), then I might need to get a little creative.

To my knowledge, dev keys have the advantage they’re free up to 7000 users. The intent is that you use dev keys to test out login for social providers (e.g. Facbook login, etc.) before committing to using your customer keys. In practice though, the only real downside I can see is that your app doesn’t display a personal logo on login and you get this annoying warning. It does leak some information about the Auth0 endpoint IP as well, but I don’t know what the security implications are for that for the wiki quite yet… (that thing at the top that says "logging into dev.<some random numbers>")

The real sticking point is the pricing. It comes out to >$100 USD per month for only 5,000 users instead of the 7,000 free users of the free plan. If the drawbacks are minimal, I’ don’t see the point necessarily. Especially given that I currently pay for this out of pocket, I don’t quite want to commit to it until it’s necessary or if it looks like we have so few accounts that it’s affordable.

They do have a discount/promotion for startups & non-profits so I’ll inquire about if that would apply here, but I don’t quite know yet.

I want to continue using it though, as I’d rather use Auth0 then to host my own user database. At least Auth0 is secure and backed up regularly, rather than trusting me to host the whole user database myself and all the headache that entails. Not to mention ancillary services like a mail server needed for email verification and such.

Ah that sounds like a lot of hassle!

Thanks for explaining! :slight_smile:

1 Like

I was having a wee look to edit a page there @scorch (after signing up via the new auth :+1: ), but if it’s enabled by default for all users I didn’t see how (I’d clicked the edit button, but it just showed me the markdown with no way to edit as far as I could see).

Am i missing something or do we need to get permission before we can edit?

1 Like

Yea, I put a link to this on the home page, but I should make it a bit more prominent I think. It’s spelled out more specifically on the wiki meta page, but the gist is that accounts, when they are signed up, belong to the Users group, and they can edit things in /user/**, view page source/history, and write comments. Depending on the subtree of the wiki, people generally need wider permissions which are granted individually right now.

Not sure if it’s maybe too restrictive at the moment, but the thinking was that maybe new users shouldn’t have the ability to start editing wiki pages about network algorithms and such.

Anyway, I went ahead and added you to the the MaidSafe, App Dev and Core Dev groups, so it should work for you now :+1:

1 Like

Ah great stuff, thanks @scorch :bowing_man:

1 Like

So when I was first looking I did have a quick scan of the wiki page, which explains the site perms, but I’d thought it was standard/default for wikijs, and not safenet wiki specific.

So I’d like to suggest some wee edits there just for clarity of skimmers.

# Safe Net Wiki: Introduction

The Safe Net Wiki is built using Wiki.js which provides a page-hierarchy similar to that of a traditional filesystem, although there are some key differences....


Just expanded a bit of the core dev topic there, providing a higher level overview of the libs and their basic interactions as well as repo links.

Was very pleasant to edit + use. :surfing_man:

In terms of site organisation, it may be worthwhile linking more pages to the welcome page. It’s not super clear there is more than what’s available in the left hand bar IMO.


At least the directory name “maidsafe” could be capitalized “Maidsafe”.

1 Like

I agree that there is need for a community wiki to aggregate information and make it more accessible. This forum contains numerous gems of information that are slowly getting lost in the vast number of posts. was an attempt to serve that purpose of curating information for/by the community. It’s still there, but unfortunately only a start, and stagnant due to my complete lack of time. I expected to be retired by now and have all the time needed.

Anyways, feel free to copy any useful content over to the new wiki.


That was a ton of work as a start though. I know what you mean about time, it’s hellishly fast.

1 Like

Ah, that makes sense, I can certainly make the adjustment. Thanks for the all your help :slight_smile:

Do you mean “from” the Welcome page and not “to” the welcome page? Wouldn’t that a little redundant given that there’s a home button in the top left (the logo is a button) and one on the quick-links nav bar?

Maybe you have an example where it caused some friction? I’m not always sure what what’s a good idea to link in the quick-links nav bar, what should just be left to the site tree nav bar, or explicitly linked inside the page.

Wow, didn’t know this existed, thanks for the resource, I wasn’t aware of this before! And as you say, it’s a bit of a time sink, especially if the information is shifting like sand beneath your feet. I think this project has only recently matured enough to hold up an effort like this.

I think you’re getting at the distinction between page pathname and page title. Let me know if this answers your question.

Directory/page path names are all snake_case by convention (also something to add to the meta page I suppose). All paths on the wiki can be both a page, and a root “directory” for other files. If a path has a page associated with it, then the page title would display in the wiki page tree instead of the page path. So if a page were created at /maidsafe with the title Maidsafe, then it would display in the file tree browser as the latter.

I did mean from yep. :+1:

For me the core docs eg we’re only visible if I go to the ‘tree’ button next to the logo. So at first glance you might not know they exist at all.

I’d guess we may want the quick nah bar to show some general topics… General Network Overview… Getting started (as you already wrote up) Core Development and Repos… Something about data ownership perhaps… then an App page.

(I know supporting content isn’t there for all that, just trying to imagine what’s be useful in terms of hierarchy)

1 Like

Ah ok, I see what you’re getting at, that makes sense. I can certainly add in some links like what you’re suggesting, and insert placeholder pages for pages that don’t exist yet. As you say, it would go a long way towards making users aware of what’s available.

1 Like