UPDATE

I think I got most -- if not all -- of this figured out. I learned about NodeBB in the process -- very impressed with it!

For posterity, take a look at the nodebb-plugin-groupthink plugin. The way I ended up solving this is rethinking the privilege setup from what I first did. Nobody has any privileges to a group's category except group members. If a user visits a group page at /groups/:groupname the group metadata is still passed to the client so the user can join the group, but the category is not retrieved. Due to some strange bug in the Persona theme (or in templates.js-- not sure) I couldn't wrap <!-- IMPORT partials/topics_list.tpl --> in <!-- IF group.isMember -->, but I solved this by rearranging some of the template html.

The plugin seems to be working well. Users can now "Post to a group" similar to how they would on other social networks.

Thinking out loud here, perhaps a good lead on this would be to figure out what generates this error. The HTTP response to get this group comes back as 403 Forbidden, which means it must be coming from the category ACL.

@psychobunny that was exactly the trick. I have updated the repo and everything seems to be working pretty well right now. Very pleased with how it is turning out!

The only seeming major block left is a problem with privileges. If I remove the read privileges from non-group members, NodeBB prevents them from seeing the "frankensteined" category/group view. I merged both views, so the user seems the same thing at both /groups/:groupname and /category/:cid/:slug, and both are restricted from viewing if the read privilege isn't given to a user.

My solution was to give the access but strip the topics out from the JSON response before sending to the client. One major problem -- they are still visible in the Recent and Popualr feeds. This tells me my solution is not really robust enough.

Any thoughts from anyone on how to get around this? I need to be able to embed a category topic list inside the group view and still let non-group members view the group page to join (without of course seeing the topics until they are a member).

Here's a screeenshot of the frankensteined view:

and to clarify the intent here a little bit: I'm very impressed with NodeBB, and I'd like to see a plugin that enables functionality not unlike Facebook groups.

@psychobunny need to update the Git repo, but in my sandbox where I was toying with this plugin I actually overwrote the groups/list.tpl so that when a group is selected it doesn't take the user to groups/:groupName but instead to to the url for the category associated with the group: category/:cid/groupName

@PitaJ sorry it took me a second to get back to you. I threw the code in Github https://github.com/aggied/nodebb-plugin-groupthink.

You'll see in the templates directory that there is a category.tpl. This is the combined version. These are the links to the originals from the Persona theme:

https://github.com/NodeBB/nodebb-theme-persona/blob/master/templates/category.tpl
https://github.com/NodeBB/nodebb-theme-persona/blob/master/templates/groups/details.tpl

The plugin is working w/ NodeBB 0.9 & the Persona theme. Thanks for any input!

I am working on a plugin that adapts the current category/group paradigm to center content around groups (vs categories). Basically, the plugin ensures every group has exactly one category associated with it, and no one has privileges for that category except the members of the group. When a user wants to "post to the group' they are actually posting to the group's category.

The beginnings of the plugin have been easy to code. I hook into filter:groups.create to automatically create a category with a group property and attach the resulting cid to the group. When the user wants to view the "group feed", I direct them to the group's category and hook into filter:category.get to attach the group to the category before it gets sent to the client.

Where I am stuck, however, is the templates. As a proof of concept for the plugin, I combined groups/details.tpl file and the category.tpl from the persona theme. The information all displays properly, including the group admin panel for if necessary for the user. There is just one major problem -- the javascript interactions on the group panels don't work. A user can't leave the group, grant/rescind ownership, etc. I need help understanding why this is so?? I spend the majority of my time in Angular, and to be honest haven't yet got a clear grip on NodeBB templating.

I am hoping this is an easy solve, but I keep running into dead ends. Would much appreciate any thoughts on this!

@baris said:

If you ignore categories, they don't show up in /unread, maybe another setting could be to only show topics from categories and users that you follow.

Yes that was trying to get at. I would very much enjoy that functionality. I would think if I follow someone I am interested in their activity on the site to help me discover things that are relevant to me. I would like to see my followees' posts regardless of topic, etc. Seems to me like it would be part of NodeBB core eventually.

@psychobunny do you think it would be large effort to start storing posts in blocks vs entire blobs? Haven't quite dug in to learn NodeBB's code just yet.

the metadata associated with each block could be something like

{
   blockIndex: Number, //the block number starting at 0
   blockType: String, //text. header, image, video, iframely embed, etc. 
   content: String,
   properties:{}
}

Been searching all around both on the Github repo and here on the community site, and can't find much of anything that describes the purpose behind following users. So I follow people, and people follow me... what gives? What's it for?

What I'm looking for is a way to drum up a "custom global feed," or a view where the user can just see a feed of posts/topics from users and categories that they follow. It seems that is the role the inbox/unread view is attempting to fill, no? If so, what are the thoughts on beefing that idea up a little bit to allow that view to pull in content from users that I follow as well, rather than just categories?

This thread is applicable to this discussion I believe. Perhaps NodeBB can leapfrog what's currently out there by a happy medium between nested comments and forked conversations. I dunno... it seems like we could allow 1 level of comments on a post, but not 2 (so no comment on a comment, only comment on a post). But --- we could build up forking functionality to allow forking of posts.

So if someone really did want to comment on a comment, they could fork that and keep going. After all, confusion and lack of context is the complaint against reddit-like discussion isn't it? If we allowed one level of comments only, and then required forking after that, it might be the happy medium. Context would theoretically always be there.

As another thought (and totally brainstorming here), what are the thoughts on a feature where when a user replies to a post they are given the option to reply in a forked thread? Very much like the "comment on comments" you see in mainstream social media.

UPDATE -- just found some older discussion on this, and was glad to see it!

@psychobunny to add to this, I want to empathize with your original thoughts here, as I have been long grabbing for a more natural conversation flow than what is found on sites today. The calendar thread is just one of an almost infinite amount of examples. Conversations aren't linear.

I can't seem to get forking to work on my install currently, but it seems the current fork functionality is different from moving a post because it copies a post into a new thread, is that right? If that is so, I would think we are headed down the right track. Take the screenshot of a Github repo network below. With the exception of the conversations being merged back into the master branch (the blue arrows that come back to the black), isn't this how conversations often happen? Maybe they even can merge back with the master, but that's a bit complex for me...

Here are some thoughts on how we could improve on the forking functionality to make for some powerful features:

• enable anyone to fork any post (not just topics, but simply fork off of a post)
• on forks, show the heritage like Github does. Perhaps just underneath the title a clickable link that says " forked from.."
• When a conversation is forked, leave a mark on the original post's card in the original topic to enable users to click a "plus" button or something to see the forked topics posts inline with the parent thread. This is almost identical to "comment on comment" functionality that has been very helpful for big sites like Facebook, etc.

Thoughts? I'm pretty passionate about this, as well as the block-style editor discussed here

@julian I hear you. There's are some pretty amazingly smart people out there who may know something I don't, but the only way I have discovered of storing tokenized JSON from traditional WYSIWYG like Redactor is to do a HTML to JSON conversion (and there are plenty of Node libraries out there that do this). While this may be a feasible solution for basic use cases, in my experience it is an absolute nightmare when we start talking about embeds -- and the modern web is clearly all about embeds.

I've been giving some thought to writing a plugin for a block-style editor, as I'll need that for my own needs anyway, but it would be great to have some help. The benefits to me are many, and there are really one two downsides: it's new for some people and you lost the ability to next images to the right of left of text (but is that actually a benefit??).

Anyone have any opinions/thoughts/interest in a block-style editor?

Still new to NodeBB, but I think the chat is handled by Redis/MongoDB. While you can store files in MongoDB using GridFS, I would think a great way to tackle that would be to have the plugin upload the file to storage (like AWS S3) and then include in the body of the message a link to the downloaded file. Permissions could be set at upload to only allow members of the chat access to the file.

I would also be very interested in this feature!

(Still new here) How can other users be added to user-created hidden groups?

The more thought I give to this (and the more time I spend with NodeBB) I'm seriously considering a block-style plugin for some of the use cases I'm thinking of using NodeBB for.

• From the browsing I've done it seems that posts are stored all as blobs of HTML, or is that wrong?

• What would it take to store posts in blocks? I'm specifically thinking MongoDB where we could store a nested array of blocks that comprise the post. Each block can have associated metadata like whether or not it is an embed, tags, mentions, etc. (This can be done in Redis as well). Mongo has performance issues when arrays grow constantly, but I'm assuming here that posts aren't typically edited to go from 2 paragraphs to 100.

Would someone with some understanding of the underlying data model and code mind shedding some light on this?

New to NodeBB, but am loving what I am finding! I have had a lot of (painful) experience with WYSIWYG over the last few years. I've even gone so far as to build an Angular version of SirTrevor.js. Markdown seems to scare non-techy types, so I applaud efforts here to get Redactor on board.

@julian said:

@shri Post content is parsed on its way out of the database, not on its way in. We try to preserve the raw content as much as possible.

So for example, the youtube embed plugin detects the presence of youtube-style URLs, and replaces them with the HTML embed code, every time the post is queried from the database.

I must admit I am partial the block-style editors like SirTrevor or Makona as blocks can remove much of the inherent problems with WYSIWYGs. Storing data in blocks enables the preservation of the raw data as well as the necessary metadata. It is a change for folks used to MS Word, but I find block-style content creation is intuitive and a better fit for mobile devices. That said, it seems the team is up to the challenge of getting Redactor onboard I am very much looking forward to it!

@psychobunny said:

I've also been looking at https://iframely.com/ (resurrected on a different thread earlier), if done right this could basically deprecate all other embed style plugins

I've been using iframely for well over 6 months now, and am an absolute fan. I have been using it in a block-style editor as I mentioned above -- and it's near perfect. Figuring out embeds in a WYSIWYG is a hairy problem, and I applaud the NodeBB team if they get that solved.

All this talk of block-style editors almost motivates me to create a plugin. I'm still new to NodeBB, but if I find it's a suitable project I just might do that.

Hey folks -- new here. Really liking NodeBB and this RSS plugin. I get an error when I add a Google News feed though. I've included that below. Any thoughts on how to go about fixing this? This is the feed I used:

https://news.google.com/?q=elections&output=rss

I've created an issue in github: https://github.com/barisusakli/nodebb-plugin-rss/issues/9

11/7 15:13 [1307] - error: TypeError: Cannot read property '1' of null
    at ELEMENTS.replacement (/home/lififorums/nodebb/node_modules/nodebb-plugin-rss/node_modules/to-markdown/src/to-markdown.js:75:70)
    at /home/lififorums/nodebb/node_modules/nodebb-plugin-rss/node_modules/to-markdown/src/to-markdown.js:100:41
    at String.replace (native)
    at replaceEls (/home/lififorums/nodebb/node_modules/nodebb-plugin-rss/node_modules/to-markdown/src/to-markdown.js:99:23)
    at toMarkdown (/home/lififorums/nodebb/node_modules/nodebb-plugin-rss/node_modules/to-markdown/src/to-markdown.js:82:16)
    at /home/lififorums/nodebb/node_modules/nodebb-plugin-rss/index.js:202:14
    at /home/lififorums/nodebb/src/database/mongo/sorted.js:325:4
    at handleCallback (/home/lififorums/nodebb/node_modules/mongodb/lib/utils.js:95:12)
    at /home/lififorums/nodebb/node_modules/mongodb/lib/collection.js:1064:5
    at handleCallback (/home/lififorums/nodebb/node_modules/mongodb/lib/utils.js:95:12)