SAFEpress: A Web App that builds websites/blogs on SAFE Network

Apps
61

Good ideas here! I like the idea of a hashed link list as it keeps it fully decentralised.

Performance wise, perhaps posters could also post an index at the same time as their post. Maybe they could hash their post along with a standard index suffix. If they make further posts, they could update their first index to speed access up for themselves and others.

Moreover, it could provide some rudimentary moderation, where you trust the poster of your choice to update their index sensibly. You could even read a number of indexes to see if they match for confidence, etc.

Once you have an index of posts, you can then take advantage of safe netā€™s distributed nature for high throughput.

This would avoid needing a gateway node to curate the data. Instead, you have distributed duration, based on who you wish to trust (including, only yourself).

2 Likes
62

Great ideas here too!

There is a key point that people need to fully absorb here - for the first time, every node on the network is essentially a peer. They are a virtual peer, I suppose. The network allows virtual peers to communicate with one another, even when they are not online.

This is HUGE and we will only begin to understand the impact of this as people begin to push the envelope of safe net.

It opens the flood gates for distributed curation of information. Previous middlemen will become superfluous and the idea of giving up this power to another party will seem quaint.

Anyway, we should really have a separate thread for these big ideas. SAFEPress will still have its place for when centralised curation is preferred.

4 Likes
63

Honestly wordpress to SafePress is a huge task. Defining the APIā€™s would be a start toward breaking up the tasks into smaller bits ā€¦

Here is the wordpress list of APIā€™s ā€“ if SafePress is going to be similar in feature/function to wordpress (and personally I think that is a great idea - building something that so many content providers are already accustomed to) then this might be a good place to start. It seems that once the APIā€™s are chosen then the individual problems of replicating it on SAFENET can be attacked with clarity.

As it is now, I feel like we are trying to swat a mosquito with a blindfold on ā€“ no offence to those who are having a damn good go at it!

64

Agreed, so while Iā€™m using WordPress to explain the vision, I donā€™t think its wise (when right now there are just two devs ā€“ myself and @joshuef ā€“ committed to doing this) for us to start with the WordPress API. My plan is in any case to start from the other end, and use the nobackend/dreamcode approach, which is a natural fit because SAFE Network is inherently a nobackend system!

What this means is that we imagine the API (dream the code) from a front-end devā€™s perspective. So any front-end devs, hands up if you would like to have a go at defining your dream front-end API, and not have to bother thinking at all about how the back-end will handle it (because thatā€™ll be the job of SAFEpress :-)).

Absolutely, all the best projects start like that! Just ask @dirvine hehe. I must admit, it gets harder whenever I sit down and try to figure out how the implementation will work, but I really think it is doable. We could use more help though, at least if weā€™re going to go beyond providing a simple CMS API for people to write HTML & Javascript on top of.

65

Sounds like it should be a blast! I have a great resource for how wordpress currently loads its sequences that we may be able to take a look at and see what options we have swapping out the php for other options or changes that may be feasible and the possibility of maintaining any current structure. But if there is a better option, all the better!!!

2 Likes
66

SAFEpress now has a website: http://safepress.io :slight_smile:

Please check it out and share.

9 Likes
67

Oooof. One day away and so much to read :smiley:

Okay, this, I think, could be a separate problem than SAFEpress itself. A less insurmountable one. As Iā€™ve said, converting to a static site is easy enough. But this interaction is more complex. However, if the user has Jetpack / JSON API installed and setup, then a static generated site could post comments to the server via this API, instead of PHP. This is an achievable goal. And would allow anyone to mirror their site on SAFE and the web.

New posts: That would become more where weā€™d need SAFEpress.

Perhaps it could be worth taking this task as a starting point. Interaction with wordrpress via a small page with a bit of JS for creating the fields needed for a new post. Then we could simply switch this interaction to saving the post to the harddrive/safe.

@happybeing I think youā€™re right, Pouch isnā€™t a necessity. But it smoothes DB interaction (from what Iā€™ve read; I havenā€™t played with it yet) and would likely facilitate the CMS instead of trying to handle this stuff in pure JS. But yeh. Not needed.

Iā€™m increasingly thinking SAFE is going to act as our DB for storage, locally or publicly and encrypted or some such. Thatā€™s pretty rad.

Final thoughts before i go to work.

@Traktion Iā€™m liking this train of thought and would go a long way to allowing more decentralisation of stuff (and ownership of your posts etc even on our curated blog).

@TylerAbeoJordan yup! very sensible thinking here.

1 Like
68

@joshuef

Iā€™m increasingly thinking SAFE is going to act as our DB for storage, locally or publicly and encrypted or some such. Thatā€™s pretty rad.

Yes :smile:

Iā€™m not clear what you mean about using jetpack installed on the client because I only know it as a WP plugin (i.e server side install). Iā€™m not sure how this is relevant to SAFEpress. Anyway, if you think itā€™s a useful approach, i.e as a useful stage in SAFEpress plan, please can you explain it, either in a separate thread or a stand alone document (e.g a github gist) so we can discuss.

Iā€™m not against PouchDB, just not planning it in or out in until we have a better understanding of how we plan to use SAFE, and what our medium term goals will be for SAFEpress. Iā€™m currently assuming SAFE REST API, but havenā€™t figured out how weā€™re going to map our CMS to it, and how client side operations will carry out the data operations we need. I was planning to have a go at that ASAP, but recent discussions about SD above make me think I need to study that more, and also get input from the team as @dirvine suggested. Not sure when the latter will be feasible though, so letā€™s see!

BTW @mvanzyl has joined us and is also looking at WordPress - he has taken a task on to look at the API so we can get a picture of what we are looking at by using WP to define SAFEpress vision (long term vision that is).

Short term I think itā€™s OK to hack a simple client side Javascript API together to show we can do some CMS type operations using SAFE storage. This will teach us a lot, and help us to define a next set of goals, such as a SAFEpress client side API/web app framework.

@mvanzyl is going to have a go at this too, defining it in dreamcode! It might be useful for us each to have a go at that and see what we come up with, although Iā€™m not sure if Iā€™ll do so at the moment.

Iā€™ve updated the tasks on github so feel free to add your activities to give all who are interested a picture of who is doing what.

Thanks again for your input Josh. Itā€™s very exciting to be getting down to building something, especial something with this potential.

69

I kinda see WordPress as being a clunky monster. Software that has been written over years and years of development tend to get handcuffed by their legacy code, and have to write a lot of stuff inefficiently because it has to work how the code was written 10 years agoā€¦ You can get it to do nearly anything you want, but with a high performance cost or a lot of engineering and optimizationā€¦ A fresh start is probably the best route, as a blog is pretty darn simple.

The idea of SAFE being the database is really coolā€¦ And it looks like the database functionality is being finalized with these unified data structures etcā€¦

In my experience, the stylesheet is always the nasty part. If we had a good editor for that, and a library of content types that you could drag and drop where you want them on the various pages, we would be most of the way thereā€¦

I would be willing to help ā€“ I have quite a bit of experience with Wordpressā€¦ I code just enough to be dangerous in about any languageā€¦ I hope to get in on the ground floor on SAFE and Rust as not too many people have a head start on me yet. :wink:

1 Like
70

@jreighley that would be great, pile in!

If you want to follow your vision, do so, and add what youā€™re working on to the TODO list on github and share your output there too, or take a look at whatā€™s there and pick something, orā€¦ :smile:

By gosh! We have a team!

71

We have three SAFEpress domains and hosting with easy app install via Softaculous. I think we could do with somewhere to discuss stuff, soā€¦ will it be a google group, or would someone like to set up a forum?

This task needs adding to the repo to-do list but Iā€™m away from github ATM.

While Discourse would be nice, we donā€™t have money for their hosting, so a simpler forum app on my hosting will do, or we could just use a google group.

72

Nope, too early for that IMO. I donā€™t want to spend much time on it until there are more concrete answers :smile:

1 Like
73

What software did you use for the new website? If wordpress, then just add in the bbpress plugin - instant forum.

74

Bumped into this today ā†’ http://octopress.org/

If Iā€™m reading it correctly, it is a client-side blogging system that uses github as itā€™s storage. Maybe the dev would be interested in helping with SAFEpress? Couldnā€™t hurt to ask.

1 Like
75

@TylerAbeoJordan itā€™s a static template, just a placeholder until someone takes an interest in creating a professional site for SAFEpress. The source is in the repo so anyone can jump in. Same goes for a forum, we have tasks ready for anyone who wants to help. Thanks for the http://octopress.org/ suggestion, Iā€™ll take a look.

76

@happybeing my jetpack chat there was in terms of how we might get current Wordpress sites w/ servers onto SAFE, but without losing functionality. (and so interacting via an API). Thatā€™s not a different question to SAFEpress, however, so Iā€™ll leave it out for now and maybe create a thread for ā€˜getting wordpress on SAFE (quick and dirty)ā€™ at a later date.

@jreighley Agree with you on wordpress clunk, but itā€™s a good point of reference / inspiration so hopefully we can just take the good bits!

Iā€™m going to start setting up something locally on a fork, just to get going. Iā€™m planning to use JS/React/Webpack to generate what would be our ā€˜safepressā€™ page, first with just some inputs and see about saving this to the filesystem. When I have something more technical for debate / example, Iā€™ll stick in an issue or PR on github. Sound like a plan, @happybeing?

77

@joshuef thatā€™s definitely a plan. Brilliant! Please stick an entry in the README.md to-do list with your handle next to it.

We have a team, and a plan! Awesome :smile:

78

If you still need a place for a forum, drop me a message. Plenty of ressource left on the wiki server, just need to set up another VM, install the forum, make a nignx rule and weā€™re ready to go :wink:

2 Likes
79

Whoa, thanks @hillbicks

I have a regular hosting service for free, and for immediate traffic needs it will be plenty, but if this takes off we might need something faster so your offer is very welcome. @frabrunelle is thinking about some website ideas so Iā€™ll wait and we what heā€™s thinking about.

1 Like
80

SAFEpress: App and permissions.

Right now, Iā€™m thinking about writing to the filesystem from a browser. Iā€™m asking as everything weā€™re considering would require writing to SAFE (a virtual filesystem) to store the ā€˜siteā€™ and any ā€˜postsā€™/ā€˜commentsā€™ they own.

If someone thinks thereā€™s (going to / could be) another method for achieving this, please chime in here!

But assuming we need this, as far as I can see weā€™ve a couple of options:

  1. A Node.js app, run locally. This would allow the browser to access via some APIs, the local filesystem etc and write to the filesystem.

  2. A Chrome / FF equivalent App. (app, not extension as extensions dont have filesystem perms as I understand it).

Does anyone have thoughts on the relative merits of these approaches? Or another option I donā€™t see?