I went with MIT as I prefer simplicity and I live next to it but I have no religion. Any thoughts?

This is item 1, in the Hackers Guide to Aardwolf

Ideally, Aardwolf will be able to send SMTP messages without having to resort to an external mailer daemon (Postfix, Sendmail, Etc). There are several libraries on Crates.io, such as Mailstrom, and Lettre, that should be able to provide this functionality. E-mails received should include the full URL in both clickable, and plain text (copy/paste) format. Using a basic template for formatting would be ideal, but is not required for the minimum viable alpha release.

Current State
Currently when a user creates an account, the auth_token is generated, and sent to STDOUT. This means that someone has to log into the server occasionally, and manually copy/paste the auth_token URL's in order to authorize new accounts.

-- Do we want SMTP functionality to be "outbound only".
-- Is there a reason why we might need to receive e-mails?

I would like to nail down the -official- process for making, and requesting changes.

Thus far, after much scolding, I've -finally- started trying to remember to make new branches, apply changes, and then PR from those. However.... for users who are not me (and me included?)... what should we do?

Here are my -current- and probably incorrect thoughts on the process

Fork -> hack -> PR -> Review -> Merge/Reject

Review is also going to be a pressing matter quickly. I think I did make some comments in the wiki regarding Governance. But we should all be in agreement there as well.

One of the VERY important features which will set us apart from Mastodon, and almost 100% of the Fediverse is the ability to create/manage Events. The precise complexity of this can vary, but perhaps we should limit the initial function to a local calendar. Perhaps with tagging people as invitations.

You don't have a fediverse account listed on the ReadMe file as a point-of-contact for the project. Eat your own dogfood! ;-P

This is item 8, in the Hackers Guide to Aardwolf

Unfortunately this is a very... undefined floating target however I will do my best to at least point out the trail heads.
These bullet points are generally going to follow order of operations as they make sense in my head.

• Build a "map" of the -existing- Mastodon functionality.
• Build a "map" of the full ActivityPub specification
• Find common links between Mastodon map, and ActivityPub map
• Translate the parts common to ActivityPub & Mastodon into pseudocode. Getting it CLOSE to Rust would be great when possible
• Take remaining parts of the ActivityPub spec, and pseudocode those
• Try to come up with a list of additional functional targets which are missing/poorly defined/not covered by ActivityPub

While working on adding the commentary provided by Prosthetic Conscience I began to stumble on the issue of Post/Content Sharing.

For context, here are the original comments:

Post Sharing:

• needs more thought. I’ve always liked being able to share with added context, but there are good reasons that Mastodon doesn’t provide quote tweeting. And if you don’t include the equivalent of quote tweeting, then you might as well use Mastodon boosting terminology.
• One advantage of the way Facebook quote-shares is that you get comments on your post from your friends.
• Maybe links and statuses/notes should be shared differently, with attribution and original comments stripped from links.

When I was marking notes last night, I thought that the solution would take the simple form of:

Source: [Attribution]
[User response to source]

Two things:

1. Does this cover the "good reasons not to include quote tweeting"?
2. Is this sufficiently similar to Facebook's "Share with..." functionality?

Trying to run master as of commit f8f0d6b

This is what i am seeing:
Probably because of a user-dum.

$ cargo run --bin aardwolf-server --features=rocket
   Compiling aardwolf v0.1.0 (/home/quixote/gits/aardwolf)                                                                                                              
    Finished dev [unoptimized + debuginfo] target(s) in 27.96s                                                                                                          
     Running `target/debug/aardwolf-server`
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: configuration property "Log.file" not found', libcore/result.rs:1009:5
note: Run with `RUST_BACKTRACE=1` for a backtrace.
$

For some environment like Tor and I2P, it's important matter to keep security as much as possible, and JavaScript could be serious harmful factor for that.
It would be better to let users have some options for that, like theme. (theme having javascript files and theme having just plain html-css)
Any suggestions?

Here it is! I hope y'all find it useful (in the future. I don't have support for Rocket yet, and the hyper and reqwest implementations are not currently tested)

https://github.com/asonix/http-signatures

The auth routes seem to have been broken at some point.

Log:

POST /auth application/x-www-form-urlencoded:
    => Error: No matching routes for POST /auth application/x-www-form-urlencoded.
    => Warning: Responding with 404 Not Found catcher.
    => Response succeeded.

Given that PR #17 is putting all of the Rocket web templates into the /templates directory does it make sense to "clean up" the /web_ui directory?

Right now it doesn't really contain anything terribly meaningful other than some sandboxing, which can be easily moved/merged into the appropriate *.hbs files that Rocket understands.

I was also going to add the other asset folders as such:

/templates
../emojo
../images
../javascript
../stylesheets
../themes

As agreed, the official name discussion issue on GitHub.

One message - one name? Which will make voting (clicking thumbs up emojis:) very easy.
And may be some explanation, why this or that name seems to be a better choice than the current one.

This is item 2, in the Hackers Guide to Aardwolf

Existing documentation should be reviewed for clarity, and correctness. There may be other portions of documentation which can be improved by being re-written, or re-organized. Other parts of the application are currently poorly or entirely undocumented at this time.

/rocket_codegen-0.3.5/src/decorators/derive_form.rs via 29:32 and 32:49

These are topics for discussion.

• Rust Task Queue (sidekiq, celery, etc...)
• Application parts (Client-Server, Server-server, API)

I was looking through the master commit log and noticed a lot of merge commits. I recommend doing what I did with tootsuite/mastodon: Allow squash merging only (Settings -> Options -> Merge button)

I've removed the Coveralls.io tag from README.md because apparently coveralls does not cover Rust (yet)
Perhaps someday, but for the time being just taking it down.

Here's the original code, if we want to put it back.

I was just thinking about the Mastodon compatibility feature... Instead of bumping the character limit to 1000 and splitting to two toots, what if we give them MUCH more space to put their thoughts, and then have it take the first paragraph of the post, and toot that with a link to the full post?

What do you think? If I can write up a backend would you be interested in writing the front end? Rust would be good I think. Either from a web server or a native app.

Could we have it as a git submodule? or maybe it's available in some package manager (npm) ?

Want to help? All ideas welcome.

I realise that learning a new language is fun but if your goal is to create a (much needed) tool that would benefit a great many people, would it not make sense to build it on technologies that already have a large developer base and are easy to deploy, host, etc.?

Don’t get me wrong, it’s awesome that you’re working on this. We are going to be working on a similar system that we initially expect ~260,000 people (a city) to use. That’s going to either be in Ruby (Rails) to match Mastodon itself or in JavaScript (Node). It would be awesome if these efforts were not fragmented across a plethora of different technologies.

(Ideally, I want to see Mastodon evolve into a federated web server of sorts – where you can deploy a custom federated app as easily as you can deploy a custom non-federated web app today using a regular web server. That would really lower the barrier of entry into the creation of projects like this one and ours.)

All that said, great initiative – best of luck with it. Looking forward to seeing it succeed regardless of whichever language it’s written in :)

There are three dependencies in the package-lock.json (used by WebPack) that should be updated to mitigate potential security issues.

Here are the recommended versions

deep-extend ~> 0.5.1
macaddress ~> 0.2.9
randomatic ~> 3.0.0

I feel as though I am reasonably close to updating the i18n branch to Rocket (master), as well as getting the rocket_i18n integrated. The current roadblock is a runtime "illegal instruction".

Build is successful, the app at least partially launches, but trying to browse creates the error.

user@MyHostname ~/gits/aardwolf $ cargo run --bin aardwolf-server
    Finished dev [unoptimized + debuginfo] target(s) in 0.57s
     Running `target/debug/aardwolf-server`
🔧  Configured for development.
    => address: 127.0.0.1
    => port: 7878
    => log: normal
    => workers: 2
    => secret key: generated
    => limits: forms = 32KiB
    => keep-alive: 5s
    => tls: disabled
    => [extra] database_url: "postgresql://aardwolf:[email protected]:5432/aardwolf"
🛰  Mounting '/auth':
    => GET /auth/sign_up (sign_up_form)
    => GET /auth/sign_up?<error> (sign_up_form_with_error)
    => GET /auth/sign_in (sign_in_form)
    => GET /auth/sign_in?<error> (sign_in_form_with_error)
    => POST /auth/sign_up (sign_up)
    => POST /auth/sign_in (sign_in)
    => GET /auth/confirmation?<token> (confirm)
    => POST /auth/sign_out (sign_out)
🛰  Mounting '/personas':
    => GET /personas/new (new)
    => POST /personas/create (create)
    => GET /personas/delete/<delete_persona> (delete)
    => GET /personas/switch/<switch_persona> (switch)
🛰  Mounting '/api/v1':
    => POST /api/v1/apps (register_application)
🛰  Mounting '/':
    => GET / (home)
    => GET / [2] (home_redirect)
    => GET /web/<file..> (webroot)
    => GET /emoji/<file..> (emoji)
    => GET /themes/<file..> (themes)
🚀  Rocket has launched from http://127.0.0.1:7878
Illegal instruction
user@MyHostname ~/gits/aardwolf $ 

This is item 7, in the Hackers Guide to Aardwolf

Part of the minimal viable product (MVP) is to get a live demo that has a "shoutbox-like" functionality. This means that users can log in, and create posts to a single local timeline. Doing so will minimally prove the concept, as well as fulfilling the need for a local timeline. Being able to tag other users, would be nice, but would require the interface to have a way to notify users (after login) that they have been tagged. One possible "stretch goal" for this target is to implement user profiles, including avatars (file-size limited due to server disk space limits).

Currently I have the language translations stored in /lang/*.toml using the TOML [table] format. It really seems to be the "right" way to do that but I'm having trouble mapping that onto the Rust-Handlebars (hbs) templates.

So far the hbs fairings seems to be looking for Structs in the key: value, format. But TOML uses `key = value" instead. Granted, I could at least -test- my theories by copy/pasting the TOML version into a Struct and playing from there.

HOWEVER (Short version):
I would prefer to read the file, and then do the appropriate operations (serde? -> hashmap?) so that the template populates with the appropriate text.

At a later point, it would be nice to also be able to define (in default.config) which language file to read.

Thought:
Could it -really- be as easy as doing {{lang/en_us.toml varible-name}} ??

Federated Search

• Each instance keeps its own index of searchable content
• Requests for content go out to each instance
  -- The instance then checks the index for the content
  -- It will then provide any matches
  -- Referencing a search index means is similar to a "See more..." in that only a small, network-friendly, preview will have to be sent.

Index example

Inspiration

• Cisco Route Summarization
• Splunk Search Heads
• ElasticSearch

Guess what I got working!!??! The Flarum discussion board :D

http://www.jaggedskybrewing.com

We should try to avoid using language features that require unstable builds of the tool-chain.

% cargo build
   Compiling state v0.3.2
   Compiling byteorder v1.1.0
   Compiling smallvec v0.4.4
   Compiling percent-encoding v1.0.1
   Compiling utf8-ranges v1.0.0
   Compiling pear_codegen v0.0.10
   Compiling yaml-rust v0.3.5
   Compiling yansi v0.3.4
error[E0554]: #[feature] may not be used on the stable release channel
 --> /home/mark/.cargo/registry/src/github.com-1ecc6299db9ec823/state-0.3.2/src/lib.rs:1:1
  |
1 | #![feature(const_fn)]
  | ^^^^^^^^^^^^^^^^^^^^^

error[E0554]: #[feature] may not be used on the stable release channel
 --> /home/mark/.cargo/registry/src/github.com-1ecc6299db9ec823/state-0.3.2/src/lib.rs:2:1
  |
2 | #![feature(const_unsafe_cell_new)]
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error[E0554]: #[feature] may not be used on the stable release channel
 --> /home/mark/.cargo/registry/src/github.com-1ecc6299db9ec823/state-0.3.2/src/lib.rs:3:1
  |
3 | #![feature(const_atomic_usize_new)]
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error[E0554]: #[feature] may not be used on the stable release channel
 --> /home/mark/.cargo/registry/src/github.com-1ecc6299db9ec823/state-0.3.2/src/lib.rs:4:1
  |
4 | #![feature(const_atomic_bool_new)]
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to previous error(s)

error: Could not compile `state`.
warning: build failed, waiting for other jobs to finish...
error[E0554]: #[feature] may not be used on the stable release channel
 --> /home/mark/.cargo/registry/src/github.com-1ecc6299db9ec823/yansi-0.3.4/src/lib.rs:1:32
  |
1 | #![cfg_attr(feature="nightly", feature(const_atomic_bool_new))]
  |                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to previous error(s)

error: Could not compile `yansi`.
warning: build failed, waiting for other jobs to finish...
error[E0554]: #[feature] may not be used on the stable release channel
 --> /home/mark/.cargo/registry/src/github.com-1ecc6299db9ec823/pear_codegen-0.0.10/src/lib.rs:1:1
  |
1 | #![feature(plugin_registrar, rustc_private, quote)]
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to previous error(s)

error: Could not compile `pear_codegen`.
warning: build failed, waiting for other jobs to finish...
error: build failed
cargo build  5.21s user 0.27s system 195% cpu 2.804 total

I pretty much guarantee that this is going to be a moving target, but I will TRY to scope out everything now. That way I we can create new milestones when new things need to be added.

Main

• Log In
• Create Account
• Base
• Error Page

Aside_main

• News Feed
• Messages
• Calendar
• Groups
• Lists
• Photos
• Favorites
• Weather
• New Event
• New Group

Main_Profile

• Profile (view)
• Profile (Edit)

Containers
These are linked from aside_settings

• Edit Profile
• Preferences
• Muted Keywords
• Muted Users
• Notifications
• Security
• Privacy
• Two-Factor Authentication
• Data Import
• Data Export
• Authorized Apps
• Authorized Followers
• Invites

The purpose of this task is to review the README.md at the -root- of the project. Since this is essentially the face of the GitHub repository it is very important that the information is accurate 🗡️

This is item 4, in the Hackers Guide to Aardwolf

Most of the UI development (at least for now) can be done independently of the Rust/backend development. In fact a separate repository has been created for any individual that would like to focus on HTML/CSS/Front-end type activities (we have non-technical ones too ;D trust me).
The aardwolf-interface repository is where that work is being tracked (mostly). It is very likely that this repository will remain as a permanent project fixture. Even as features are ported over to the main repository it will still be nice to have a place for people to test layouts.

/templates -- is where the bulk of the Tera-syntax HTML lives. Please feel free to use filler-text for testing layouts.
/web -- is where the static assets should reside.

Hopefully the sub-folders are self-explanitory...(unlikely x.X, but will fix later)

Tera Syntax (40,000-foot-view)

Reusable text that goes into the Language/translation files looks like this:
'''{{ variable_name }}'''

Templates can be included as part of another page (think PHP include()) as such:

'''{% block file_name %}{% endblock file_name %}'''
Where file_name is the actual name of the *.html.tera file. File paths are not required (IIRC) because Rocket will find them.
You can also have "fallback" html for those times when a block becomes broken:

'''
{% block new_post %}

This will render even if "new_post" will not!

Tera documentation is found here:
Tera Templates

This might be more user error than legitimate issue, but when trying to install aardwolf, I get this error:

` Compiling ring v0.11.0
Compiling r2d2-diesel v0.99.0
error[E0583]: file not found for module montgomery
--> /Users/ghost/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.11.0/src/arithmetic/arithmetic.rs:15:9
|
15 | pub mod montgomery;
| ^^^^^^^^^^
|
= help: name the file either arithmetic/montgomery.rs or arithmetic/montgomery/mod.rs inside the directory "/Users/ghost/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.11.0/src/arithmetic"

error: aborting due to previous error

error: Could not compile ring.
warning: build failed, waiting for other jobs to finish...
error: build failed
`
However, arithmetic/montgomery.rs exists.

It looks like this is a known issue with a fix coming, but I don't have a solid enough grasp on Rust to fully understand what the issue is, exactly, or if there's a workaround in the meantime.

Something like

pub trait FormWithState {
    type State;

    fn as_state(&self) -> Self::State;
}

impl FormWithState for CreatePostForm {
    type State = CreatePostFormState;

    fn as_state(&self) -> Self::State {
        CreatePostFormState {
            ...
        }
    }
}

And this could even be automated with proc_macros like this

#[derive(FormWithState)]
pub struct CreatePostForm {
    name: Option<String>,
    #[form_with_state(ignore)]
    csrf_token: String,
    ...
}

@the-sillystring should probably update the project description. "fac3book" could still cause us some legal headaches.

What should we name the project?

Ref: https://github.com/the-sillystring/fedibook/wiki/Genesis

There are a lot of use cases in which using an external mail relay would be good. For instance, my site leotindall.com uses MailGun because it doesn't have a good enough reputation to effectively send mail. Whatever is done regarding mail, I suggest first class support for setups like this.

Basically what the subject says. Not yet sure how to fix that though :'(

quixote@willow ~/gits/aardwolf $ cargo build
   Compiling aardwolf v0.1.0 (file:///home/quixote/gits/aardwolf)
error[E0277]: the trait bound `rocket_i18n::I18n: rocket::fairing::Fairing` is not satisfied
   --> src/bin/main.rs:116:10
    |
116 |         .attach(rocket_i18n::I18n::new("aardwolf"));
    |          ^^^^^^ the trait `rocket::fairing::Fairing` is not implemented for `rocket_i18n::I18n`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0277`.
error: Could not compile `aardwolf`.
warning: build failed, waiting for other jobs to finish...
error: build failed
quixote@willow ~/gits/aardwolf $ 

We need to aggregate a list of columns that should have unique constraints so we can go ahead and write those migrations.

• email column in the emails table
• shortname column in the personas table
• user_id column in the local_auth table

and probably more

What format do we want to use for configuration files? I'm fairly partial to a simple key=value pairing like what is used by a lot of Linux software. It's simple, easy to parse, easy to read/write, and can easily be extended if we need something more advanced.

Other options I think are worth considering are TOML, JSON, and XML.

I've been getting this really annoying error about "cannot build libxml", and apparently I'd fixed it on ONE system but not others, and I never bothered to write down the fix.

When running

cargo build -vv
I -eventually- found this:

cargo:warning=src/helper_functions.h:6:29: fatal error: libxml/xmlerror.h: No such file or directory

Which is likely because I did not not have the libxml2-dev package installed.

Install it with the usual apt install libxml2-dev way and you should be good to go.

This is item 5, in the Hackers Guide to Aardwolf

In order to provide better guidance for development it is sometimes useful to have visual depictions of how data flows through the system (application). While we do not necessarilly need diagrams for every detail, we should at least consider building them for the major functional parts, and anything which might need clarification.

• What does a post look like?
• How do we federate?
• What data is being passed during federation
• What would a search look like?
• Local functions/simple DB transactions. Update records for items like profile data.

We also need to take in data from other services (PeerTube, Matrix, Photo Sharing, File storage). These are all "Stretch goals" but planing ahead does not hurt.

@jfmcbrayer suggested that we adopt Rust's Code of Conduct.

I agree and I think we should adopt this as a foundational CoC.

Unfortunately I have not had enough spoons to fully understand how to route from Rocket to the full set of templates. So I figured I would post this as an issue. Plus it would be a good "beginner" issue for the Rust Community folks

• Route to template files
• Get tempaltes to "populate" with appropriate values (like PHP include(), as well as files in /lang

Due to the very volatile nature of rust nightlies I would like to know what it would take to switch away from Rocket.rs to Actix-Web, or perhaps Hyper.rs to reduce the need for rust-nightly.

Actix - https://actix.rs/
Hyper.rs - https://hyper.rs/

on wearesocial.tech, after the github login, the popup window stays open and has the following in the URL:

The redirect_uri MUST match the registered callback URL for this application

This is item 3, in the Hackers Guide to Aardwolf

The web interface for the application follows the Tera syntax for populating the content. Rocket can use several template formats, however Tera was written specifically for Rust. Previous versions of Aardwolf templates used the Handlebars format, which is more geared toward JavaScript users. One point of interest is that the Handlebars templates rendered, and simply rendered the variable names. However, Tera compiles but throws an error during runtime because the variables are not, yet, tied to specific value.

The language files live inside of /lang, and are simple key=value pairs using the TOML syntax. When the app loads it should scan the /lang directory to ensure that at least one valid language file is present. All of the key=value pairs in the language files are stored in a struct (/src/aardwolf/lang.rs) that is used to parse the files more efficiently. Currently there are two places where the language files can be configured. The main aardwolf.toml, and the user preferences dropdown.

This feature is being tracked in the a-i18n-langages* branch: Shortcut here --> a-i18n-langages

(footnote) Why the hell would I spell LANGUAGES correctly -.-...

The setup binary fails to report database creation failure.

Cause of failure:
configured user does not have CREATEDB permission.

Expected Result:
Error reported and setup program terminates.