A thread for is has been created at https://f-droid.org/forums/topic/pjuu/

In the About Us page, you mention the GNU AGPLv3 license. I think making the license text into a hyperlink is very important.

Pjuu is an open-source social networking application released under a "free as in freedom" license, the > GNU AGPLv3.

The link.to the license is here: http://www.gnu.org/licenses/agpl-3.0.html

I made a mistake when designing the data layout in Redis.

All hashes are referred to in lists some where, for example all posts a user makes have there IDs pushed on the users post list (user:posts:$uid)

This allows us to delete all posts by iterating through this list and removing the each corresponding "post:$pid" from Redis, which in turn allows us too delete all comments and votes attached to the post (post:$pid:comments, post:$pid:votes).

There is no similar list for comments. Comments are stored on a comments list related to the post they are comment of ("post:$pid:comments").

This means there is no way of identifying the comments a user has made across the site as these are not relational to the user (would be different in a relational database). The user can still delete the comment if they are within the post (they can't right now, see issue #2), but we can't find them all to delete each one.

Unlike the lists full of IDs such as votes, feeds, followers & following (sorted sets), which do not cause any privacy issues as we can not identify the hash associated, these will leave a remnant. We will not be able to see who created the comment but we will be able to see the content and the voters. This can't happen!

There is a solution to this. I am going to have to implement a new key "user:$uid:comments" which will give us the same delete procedure as for posts. I am skeptical about this as we may run in to issues with heavy commenter (this could happen for heavy posters also), we will have to come up with a better/long term solution in the future, IF the site starts to grow.

This list will not self clean like the posts queue or comment queues on the posts as it will not be accessible (at the moment). So we need to bare that in mind.

We are also going to have to add all comments to the list that exist now. We can do this quite easily whilst there are such few comments with a simple script.

This issue will stay open until this implemented and corrected within Redis. The timescale for this is by Friday with the rebuild of the platform and the release of 0.2dev.

These are some of my ideas for Pjuu.

• Click-able and viewable full-size profile picture (from clicking the profile picture from the user's profile page) Will fix in #104
• Sound on new alert (Not going to implement, as the method should be thought about on all platform and we need an API and the likes first)
• Direct Messaging #107
• Posts per Feed page selection will add in #106
• The ability to choose how many alerts there are on the notifications page. #106
• Un-doing an upvote or downvote see #85
• Blocking of users (will roll in to #46)
• Hashtags (#53)
• Groups wont add.
• Maybe Ctrl+Enter to submit a post Up to your browser
• Maybe bulk deletion of posts I think post deletion should be thought about, just as post creation.
• Daily digest email (Of alerts that happened in one single day) We don't want to spam. Not a mailing list
• Data import feature (the opposite of the already existing data export feature or data dump) Far to many privacy/security concerns. People could duplicate accounts with web scraping
• Clear all notifications see #67
• A clear notification system that actually deletes the notifications Not possible due to nature of them see #67
• Overview, part of the text in the notification Not plausible.
• Date of user's registration
• More preferences in the settings area
• I think that if a post was made and it notifies the user of that post but then the post is deleted, then the alert item should be removed form the alerts list/page
• Once on the profile page, if the end-user clicks on the profile picture of the profile he is viewing it should then open up that profile picture direvctly (URL). #104

The master branch does not pass builds at the moment due to re-factoring work taking place.

We are re-factoring all aspects of Pjuu to correct some design decisions made earlier. We are also carrying out the following:

• Moving to UUID based uids, pids, cids and aids
• Cleaning up unit tests to work with these IDs and going for 100% coverage and 100% functional testing.
• Changing the Redis keys to use hash tags "{}"
• Ensuring no race conditions inside Redis which could compromise privacy.
• Moving tests out the Pjuu app into a 'tests' folder
• Cleaning up the backend functions and views.
• Probably some other things.

As Pjuu is not 1.0 yet we are going to brake backwards compatibility. This is only because the Redis keys are different. A migration script will be provided.

I would like to point out that there are no issues with circular imports in Pjuu.

The problem arises when I want to delete posts within the delete account function. This causes a circular import and also does so in the alerts system if I import it.

At the moment the code for the delete_post and delete_post_replies is duplicated in the delete_account function. This has always been the case, but its nasty.

The functions which cause this are all for getting user names and user IDs. I will probably add a helpers module to the auth class which all other classes can use for these functions.

When deleting posts/replies if there is an image upload attached these are NOT being triggered for deletion in GridFS.

I will fix this soon and clean up any uploads that have been left dangling.

Note: Requires Unittest's.

Convert the docker image to Jessie rather than Wheezy.

There are some issues with the required libraries that need to be tested.

I also need to have a method for created the indexes in MongoDB. I know the indexes are created in pjuu.lib.indexes but I don't want to run this every time a new Gunicorn worker created a Pjuu app. Will work this out.

When signing up some extra checks need to be implemented for the email address field.
Triggering the bug is causing users to be dropped on an ugly error message

Steps for Reproducing the issue:
<Ensure previous sessions are clear and/or you have signed out>
go to the sign up page
fill in the form. Ensure to include a bad character in the email field ( # for example )
click submit.

I am opening this issue so I can keep a log of research and plans for the future implementation of this feature.

Similar to other social networking software which have tried with some success I would like to implement federation in to Pjuu.

Federation will allow different people to run the Pjuu software of their own servers and connect these together. This would allow a user at, for example pjuu.com to communicate with a user at example.com. This should allow these users to know that their data is kept at their Pjuu instance.

I have some ideas of how this should work but I will need to learn a lot more before any work can start. I would like the design of this communication to be implemented outside of the Pjuu software. This will allow alternative implementations to communicate across this network.

There is some security and privacy questions I will need to answer.

I will try and put everything I learn in to this issue as a central place before any work can start.

To implement this it would probably be best to move all of Pjuu's core functionality in to an API that the frontends would be able to use. I also need to plan this out. It will be relatively simple to achieve. I have thought about this extensively in the last year.

It's about time we got some :-) Thanks @mcrmonkey for the idea, I know we are copying.

If you fancy doing some R&D on what end points we need that would be ace, will post here what I find.

This is planned for 0.9 (will tag in a bit). Going to change the way posts work I think so everything is processed when adding one. Going to be needed as that will give us all 3 mentions, URLs and hash tags. Going to have to look in to parsing URLs without Jinja (can still use it though :)

With the work going on in rework/mongodb there is going to be some fundamental changes to they way posts and comments are stored.

All the data needed to display these will now be stored along with each document. All the tagged users, the positions of these in the text, the authors user name and anything else that can be thought of.

This will make the write path slightly slower but will drastically increase the performance of reads.

No longer will reads need to go back to Redis or Mongo to look for any additional data.

Moving to Mongo is making the code a lot cleaner and by that extent a lot less error prone.

With MongoDB we are not spoilt for space compared to Redis alone so we can afford to do this.

I'm putting this here so I can mark the commit in the branch that gets round to adding all of this stuff!

I need to create the migration script from 0.5 to 0.6. It's going to be a big one.

To reproduce:
Settings -> profile
type a new message in the about box and click update profile
page will return "profile has been updated" but about box will be populated with previous profile data.
Clicking "profile" or settings reloads the page with updated profile info.

This is not a show stopper though.

A small number of us have said that a larger character limit may be useful.

This will allow better conversations to take place.

500 characters seems like a good idea :)

The time has come to get rid of version branches. I copied this idea from things like Flask and Redis but it doesn't really work in our case. We need a new system.

I think Github Flow would work best, after all we use Github and we may as well follow in the footsteps. They know a lot more about Git than I do.

https://guides.github.com/introduction/flow/index.html

This will not come in to play until version 0.6 and all the work has been done to complete the move to MongoDB.

This is a note for me to fix this in master (0.3dev) and deployed (0.2.5).

If an account is deleted and then the name searched it will throw an error:

UndefinedError: 'None' has no attribute 'email'

I have forgot to filter missing user accounts from the list. By missing I mean the lookups keys get assigned the uid -1 which will always return None when get_user(-1) is called.

This will be fixed soon.

This is tied in with the comment re-ordering.

Reminder to complete. This needs designing.

If any one has any ideas please let me know.

Users with inactive accounts are able to change their passwords.

Reproduce:
Create an account as normal on the site.
Ignore the activation email.

Return to the site and click the forgotten password link.
Fill in your email and submit

click the link inside the forgotten password email
fill out a new password.

I originally had the comments back to front so the newest was at the top.

This seemed okay but it is very counter intuitive and may make people not bother.

TODO: Re-order comments so they flow from oldest (lower pages) to newest (higher pages).

The test suite repeats itself a lot.

We want 100% test coverage and great functional testing. This isn't that easy at the moment.

The test suite should be broken down a little without unnecessarily inflating the test count, it is probably far to low at the moment and we rely on Pythons exception handling a lot to point us to the issue rather than the test number.

After speaking to a friend at work we can also make the tests quicker with setUpClass() but we need to make the tests not so reliant on the database being clean between each case.

Will have a think and post a more detailed list of what we are to change and how we are to reorganise them.

So that new users don't have empty feeds until someone posts something and to allow them to get in to the conversations early, when you follow a new user it should place a couple of their post's in to the users feed.

The work has been done to move the feeds to be sorted sets which allows this.

If you click an image in a list of posts or on the view post the image opens in full screen.

On a list of replies it does not do this. I need to jump straight to the full screen image, basically skipping one step for the list of posts.

Since a lot of the data is going in to MongoDB and space is less of an issue inside Redis I am going to move lists to sorted sets.

This will allow us to fill some users feeds with content as and when they follow new people.

We can't really do this at the moment without the feed items become all messed up as there supposed to based on time.

This needs some thinking about and it will mean all feeds have to be re-populated when the migration happens.

URL is being created with the wrong user name. It is not using the original posters user name, but the commenters.

Tag highlighting within Pjuu isn't very good we need to make it more robust.

The regex could be better

(?:^|(?<=[^\w]))@(\w{3,16})(?:$|(?=[.;,: \t]))

Since moving user accounts from Redis to MongoDB we need to ensure new accounts are expired if they are not activated within 24 hrs.

This is the same as the current deployed version of Pjuu but this needs implementing in MongoDB.

We also need to reserve User names and E-Mails for 7 days once an account has been deleted, this will stop abuse (this requires some thinking).

Sarah has an issue where her alerts time is not being set.

There is an alert showing in her alerts tab although she's checked it.

I will investigate some more.

The templates don't really make sense for followers/following list because the it goes from oldest to newest. So the pagination buttons are the wrong way round.

Also you probably want to see the newest follower first so it makes sense to switch the ordering,

This is a massive oversight in a template update. This is fixed in the new_design branch. Will not backport at the moment as new site goes live Friday. Will close issue then. Please be aware.

This does not affect deleting posts. All comments will be deleted during this operation.

Allow users to lock down who can see there profile or any posts they post.

I think it would be great for the user to have more settings in the settings area, such as:

• The ability to enable HTML refreshing at a certain interval for the suers' feed
• Ability to change your color scheme (basic themeing)

spotted in the logs that common files ( favicon for example ) are redirected to the sign in page for non signed in users: /signin?next=%2Ffavicon.ico

expected behavior would be to just give the file out to the user and not require sign in.

It would be nice to remove posts from your feed. It is not a feature I would use but the option would be nice.

I have made the timestamp() function a little more accurate so that the unit tests on my Mac book pro passed.

The problem was that using timegm(gmtime()) was only giving me an integer (yes I know I could have users time.time()) however I decided to append the time.clock() value to the end.

This works on my local development environment and seems to always give me a unique time stamp. Yet when run on Travis I seem to have the same problem.

I am sticking this issue here so you can be aware of why the build is failing at this present moment in time.

https://travis-ci.org/pjuu/pjuu/builds/35658309

Remove the complexity in the URLs. We should redesign them more a long the lines of a API.

For example:

/<username>/<post_id>/<reply_id>/delete

Gives semantic meaning to the URL in a way that is very convoluted. reply_id is a reply to post_id which was posted by username. That is a little silly. It may have made sense a year or two ago in my head but it no longer does.

There is also the case where:

/<username>/<post_id>/delete

Does the exact same job but with no reply context.

I do not know the correct schema but I will give it some thought over the next couple of days. It should be really simple to write and navigate manually.

There is also some issues with semantics from old stuff is still present within the URLs.

Old account not sent email when changing email address on account

Reproduce:
Alter account email to something different

Will there be an easy installation script or some documentation on how to install *Pjuu?

Thanks in advance. 😄

As with the issue #19 I have decided to remove the concept of a separate object for comments. I am listing this here as it will be a MASSIVE difference and require a bit of migration work from the current Redis store.

Everything will be a post and a comment will be identified by a reply_to attribute on the post.

The presence of this reply_to attribute will also dictate which route the post makes when being submitted.

Posts and "comments" will still be posted at different URL's but as far as the code is concerned it will treat these as the same thing. Replies will NOT be viewable on there own (like Twitter) because I think this causes a lot of confusion. They will be explicitly stopped from having a "/username/pid" URL. They will however still be deleted and voted up on exactly the same as posts now.

The URL structure may change in the future to reflect this change. As I work on it I will keep this issue updated.

Sarah has a Samsung Galaxy S3 and it the image upload button does not work!

Will need to investigate this.

A Restful API would be nice so we could make a proper Android/iOS app rather than use a web view.

There are parts of the UI that would be much better if they made Ajax style calls for various tasks.

Deleting posts, voting, etc, would all benefit from not changing the flow due to page reloads.

We need to write this in a way that keeps compatibility with text based browsers such as Lynx.

Implement suggestions for people to follow. It is very hard to find people I would imagine if the site is public.

There is some clever sorted set stuff we can do in Redis to make this a little less painful.

For 0.7 (release after Mongo release) I will add in image uploads.

MongoDB was added to aid with this and simplify our stack. Images will be stored inside GridFS on MongoDB and there will be a /media url added which will be able to reach in to GridFS and return a desired image.

To speed this up all of the correct headers will be set so that these images can be cached at a web server such as Nginx or Varnish.

Error pages are not handled by the Pjuu application and some should be.

To allow scaling with properly with proxy server (Nginx) and Docker we are going to have to change the error handling.

I though it was a good idea to have Nginx read the errors from disk and server them itself with proxy_intercept_errors on;. So only the error codes come back and Nginx was serving them. This meant Pjuu just returned the standard Flask error page. Even the maintenance page was served this way but this doesn't scale.

The plan is to have application errors handled by Pjuu this is really simply using Flasks errorhandler decorator.

Some errors will require true static files to be served by Nginx. Our maintenance page is an Nginx thing which reads the Pjuu static which only worked when those were being served off disk by Nginx. They are no longer being served due to cache busting and if Gunicorn restarts and is separated (Docker) these files will not be served. So to that end maintenance and future errors such as flood control need to be part of Nginx configuration and not Pjuu.

This error is a bit of a ramble but I am just putting down my thoughts. This needs some edge cases, decisions and research doing so I have a good solution.

These need sorting out as they are not very efficient.

The alert mechanism is very simplistic but it works.

It could possibly do with being cleaned up as I am not truly happy having jsonpickle store an object in Redis.

It may be nice to mark these as read. You don't want to get an alert if you are already on a post and have seen the comment and you don't want them to be all marked as read when you visit the alerts page.

Don't know if this will make it in to 0.9 as there is still a lot of work to do but definitely 0.10.

For the release of 0.6 I will add a very simply dashboard with statistics.

Total users, total posts, number of active users, number of posts which are replies etc...

This will help people see what is going on.

In the future this dashboard can expand for conflict resolution, reporting and moderating users such as muting, banning or deleting them.

When you are deleting posts from the profile page it bounces you to the home page after each deletion.