Need to implement keypair generation, wire into the publicKey field in actors, and actually do the signature stuff (probably with https://github.com/asonix/http-signatures).

It would be nice to allow guests to browse the posts that have been made on the rustodon instance. This is a nice way to attract users and help spread the word about rustodon.

Or, what do we need to do so that Rustodon isn't useless?

ie, docs/stories.md but more specific

Implementation goals

• publish users as ActivityStreams actors (cf this)
  • basic structure
  • publicKey for HTTP Signatures
• inbox (cf this)
  • validate signatures

Mechanics

• We might want to use @asonix's AS/AP crates instead of our current, extremely ad-hoc serde_json-ing
  • I don't know if those crates do anything actually JSON-LD-y or if they're fancy serde_json wrappers. Figure that out, decide if we actually want JSON-LD, and if so, maybe talk to @cwebber about that?

• in- or out-of-process?
  • ie, worker processes or worker threads
    • see threadpool
    • see rjq
• storage backend?
  • can we contort postgres into fulfilling our needs? (kroeg did, but we probably shouldn't. we'd also probably have to use pg-specific stuff and that would create porting issues with #12)

i know @yipdw has Thoughts, it would be good to serialize them here maybe?

see also my post on r/rust, where people basically went 🤷‍♀️

dumping things here for myself or other people implementing this

existing code for worker pools n stuff

• https://github.com/rust-threadpool/rust-threadpool 🌟
• https://github.com/sfackler/scheduled-thread-pool 🌟
• https://github.com/kureuil/batch-rs 🌟
• https://github.com/reem/rust-scoped-pool
• https://github.com/Kimundi/scoped-threadpool-rs
• https://github.com/rphmeier/jobsteal
• https://github.com/darshanparajuli/jobpool
• https://github.com/davidpdrsn/robin
• https://github.com/mehcode/schedule-rs
• https://github.com/fede1024/rust-scheduled-executor

what do we want the interface to look like

what happens if rustodon(1) crashes when we still have jobs hanging around

if they're, eg, deliveries, they need to be retried when it comes back up.

there are methods (for postgres, SKIP LOCKED) to build work queues in database, but we don't really care abt that because we don't have multiple worker processes, and we can dispatch jobs to worker threads entirely in-core. what we really need is a journal table of jobs that have been started but not completed; when the app comes up, we read the journal and reissue those jobs

Ideally, non-master builds would be built in debug mode so we are more empowered to investigate should something break.

Since the CI emits a release candidate when successfully compiling "master", that should be the one place where we produce a release build.

I have noticed the rust target/ directory, when compiled, is about a gigabytee ... primarily because of:

.../deployment-archive/target/release$ du -hd1
780M	./deps
599M	./build

This will bloat any remote server drastically.

Naively I would imagine that a build artifact at this point only requires the rustodon binary and perhaps the migration scripts.

I am not familiar with rust, and all my googles should that rust is still in flux when it comes to best practices for packaging outputs.

Things I would like to do:

• confirm whether we actually need to keep source and intermediate binaries in the final build artifact
• modify travis to be more selective about what it includes

rust-lang/rfcs#1925

It's possible to take the package in a different direction from the ecosystem, but it's not gonna be easy. Rust itself doesn't really accept user feedback, which can cause some real issues sometimes.

I like to believe it's gonna be different this time, and I hope for the best, but I'm still a bit worried about it.

Tracking issue. TODO: fill in stuff here.

Remote instances should be able to follow local users; the correct AP specified behavior should occur and we should record that this happened.

This probably shouldn't happen! it puts a huge horizontal scrollbar on the page. Let's do something like overflow-wrap: break-word?

we want to bubble errors up so that db errors actually 500 instead of just returning None and 404ing

Hi,

And thank you for working on rustodon. That's an interesting project to try and reimplement an ActivityPub app in Rust 👍

However, i noticed the certificate on https://rustodon.glitch.social expired two days ago. Coming from letsencrypt, it shouldn't be too hard (whether with certbot, acme.sh or others) to have it renewed automagically :)

Let me know if you need help with your cron/ACME setup!

We don't receive statuses yet, but it would be good to impl.

It would be nice to support Secure Quick Reliable Logins.

Sorry for the short issue, don't have much time just at the minute.

We can unit test a bunch of stuff relatively easily, and we really should.
An incomplete list:

• webfinger
• nodeinfo
• validators
• AP actors/objects (subject to change, if we write more abstractions around them)
• bio/eventually post escaping

(via @yipdw on #24):

.add_private() is good, but I'm not sure where secret_key is set. If we don't set one, Rocket will
compute one at startup; however, this means that cookies won't be readable across server restarts.

Maybe it would be a good idea to add an example Rocket.toml with a secret_key that is rejected by
default (so that one must be generated before starting Rustodon)? This could probably be served nicely
by its own issue, I guess.

it's still stuck on 45525c3. any ideas, @rustodon/ops?

Easy to implement and a good first step to get the timeline logic fleshed out!

Statuses mispaginate on profile pages (latest status is always cut off when going back to main page).

Consider adding 'top' max_id target via an enum and custom FromForm impl.

Dependabot can't resolve your Rust dependency files.

As a result, Dependabot couldn't update your dependencies.

The error Dependabot encountered was:

error: failed to parse manifest at `/home/dependabot/dependabot-updater/dependabot_tmp_dir/Cargo.toml`

Caused by:
  the cargo feature `default-run` requires a nightly version of Cargo, but this is the `stable` channel

If you think the above is an error on Dependabot's side please don't hesitate to get in touch - we'll do whatever we can to fix it.

You can mention @dependabot in the comments below to contact the Dependabot team.

If we don't implicitly perform fetches in database helpers like User::by_id, we can compose them: see this chunk of the Diesel docs.

i messed up and merged #87 a bit impulsively! if you could take a look at status pages, @y6nH, that would be great!

Users should be able to get to their own profile from the home page.

While we're at it, we might as well move the 'edit profile' link to the user profile page itself.

thanks, @CosineP 😃

Bios should linkify mentions, URLs, and hashtags.

#5 (comment)

For bios and statuses, it's extremely important that we can parse a chunk of text like

@[email protected] yeah #rustodon is great, check it out https://github.com/rustodon/rustodon

into some entities that describe where {mentions, hashtags, urls} are in that text.
This can then be used to process mentions and hashtags, as well as linkifying them.

Mastodon uses twitter-text with some tweaks. I looked at egg-mode-text, a Rust port of twitter-text, but, unfortunately, we have to change the way mentions are parsed, so that won't work. It's a good starting point for our implementation, though. The main differences between twitter-text and what we're trying to do are

• mention structure
• no cashtags
• no linking of short ASCII-only domains
• no special handling of t.co urls

Maud tends to discourage first-time contributors from touching the markup.

@netshade suggested askama as an alternative, providing type-safe, compile-time Jinja2-like templates. I think they're planning on working on implementing them, too, so for now I'd consider this issue taken.

I'm just gonna say pipes at the start of match branches are a highly disliked Rust feature, i.e. there was a lot of feedback against it, but it still got added to Rust anyway, against the users' feedback.

please don't lock issues just because you don't quite understand them. :/

please try to keep the rust community away from this project, as they'll just poison it.

• Bikeshed a style config (the hard part) (#9)
• Enforce as part of the pull request workflow (probably with Travis)

As in title.

Mentoring instructions

Use validator as in SignupForm on CreateStatusForm; something like #[validate(length(min = "1"))].

• users can change their password
• users can reset their password (requires email! terrifying...)
• users can delete their own account

We should probably get a person on this who is actually Good at positioning the boxes.

right now we're just treating account.summary as PreEscaped html. to make an actual bio form, we need to properly sanitize the input or just switch it to non-pre-escaped; i'd prefer to do the former, since we can linkify links then.

As the frontend grows, I'd like to be able to use SCSS for preprocessing the CSS and templating in variables. If nobody minds my adding Sass as a dependency, I could add it as a step to build.rs.

I don't know if this would make CI harder (boop, @yipdw, @RobotDisco).

• Schema column for content warnings on statuses
• Serialization of content warning field to "summary" property on AP status objects
• UI for adding CWs to a status when composing (basically just add a form field and make content_warning None if it's empty and Some(_) otherwise)
• UI for displaying CWs on statuses on the profile page and status pages

this is seriously a pretty small change change! things you might want to do:

• factor out the status display logic from the profile and status pages to a single source
• figure out how to do CSS-only content 'show more' content collapses

@dexamphetamine, you wanted something to work on; this might be a great opportunity!

When testing basic functionality (assumed: ROCKET_ENV == development), it seems like the default https protocol and requirement for DOMAIN to be explicitly set could be relaxed.

Does it seem reasonable to make it such that in development:

DOMAIN defaults to localhost and the bound Rocket port

Additionally, instead of using https for protocols, the leading protocol adopted is //, to bias to the browser's protocol that is used to connect to the site?

This is something I was posting about on Masto and @ashkitten suggested you might want it brought to your attention here as something to think about, so here goes. Note that I'm not really familiar with how Rustodon handles URLs so I'm just assuming that you do things approximately like Mastodon does; feel free to adjust or ignore this issue to meet your actual situation.

Right now on Mastodon, status IRIs look like this:

https://glitch.social/users/kibi/statuses/100280709188146130

And the user-friendly URL version looks like this:

https://glitch.social/@kibi/100280709188146130

Both of these URLs work fine from a technical standpoint, but they're extremely not user-friendly (user-friendlyn't) when it comes to writing them down or publishing them in print or anything that might involve manual input.

Use-cases:

• An organization with a Rustodon account might want to print a link to a status on a flier.
• An individual might want to write down the source of a quote in a notebook for later use.
• A print publication might want to cite a toot in its bibliography, and readers might want to verify the source.

It might be too late to change the IRI form of statuses (since they are the canonical representation of a status, having them be print-friendly would be ideal since they would be the preferred link to cite in a bibliography, but if you have any Rustodon servers currently in production it would mean either grandfathering old URLs or else breaking federation on old posts), but the URL form should be flexible at least. The three following representations should be relatively user-friendly as public-facing URLs:

1. A case-insensitive Base32 representation, omitting the confusable letters I, O, S, and Z. (You might also want to replace L with _ or make similar adjustments.)

   https://glitch.social/@kibi/02R24QQ8FPLXG
   

   The advantage to this approach is that the URL is shorter, contains a wider diversity of characters, and is case-insensitive, which will generally make it easier to write down.

2. A case-insensitive Base32 representation as above, split into hyphenated groups.

   https://glitch.social/@kibi/0-2R24-QQ8F-PLXG
   

   This is a little longer than the first approach, but much easier for eyes to parse and humans to input.

3. A case-sensitive Base64 representation.

   https://glitch.social/@kibi/0FkRMYQ-9PS
   

   This gets the maximally short URL, but users may not realize that the URL is supposed to be case-sensitive, and there are a number of easily-confusable characters.

I've prefixed the above URLs with 0 to distinguish them from decimal URLs, making it easy to set up redirects and support both representations. I don't know if this is something you'll want or need or not.

The current init files are written with a metric tonne of "I don't know what I'm doing". Because of this, they don't log rustodon output and possibly aren't easy to trace or programtically confirm whether they're running, expecially in the context of content delivery.

As a core developer, if Travis/CodeDeploy fails, there should be a clear artifact I can use to follow the events that lead up to the services' failure.

For default values, use multiple classes, e.g.

<div class="default-light-bg navigation"></div>

This is better than using CSS preprocessors because unlike CSS preprocessors this makes an attempt to keep your webpages (well, their CSS, at least) small. Smaller webpages = faster loading times.

#5 (comment)

It would be nice if all the code that implement the basic ActivityPub primitives would be accessible in a standalone library crate.

It would be very useful for developers trying to do other AP-related projects. It would also be better software design for rustodon, IMO.

• separate Diesel code out so we can use proc_macro #21
• wire up Maud #22
• reach feature parity with existing Tera templates #22

Is there some sort of bug in Cargo's semantic version resolution? 1.32.0 seems like it should be > 1.31.0-nightly. Specific error message:

Installed version is: 1.32.0 (2019-01-16). Minimum required: 1.31.0-nightly (2018-10-05).

I'm thinking of how I can make posticle more portable and useful outside of the rustodon, since there are probably cases where this functionality would be useful to others, and besides that, it'd improve the quality of the code.

The first thing that needs work, as far as I can tell, are emoticons. For the utf-8 icon based emoticons there isn't anything additional that needs work, however we need an EntityKind for custom name based emoticons.

Once that is done, I want to move the HTML generation into positcle, I've identified three cases where posticle syntax is used:

1. In user titles (e.g. Measly Twerp :archlinux:)
2. In user biographies
3. In user posts

For titles it doesn't make sense to support hashtags, mentions and URLs, but we would want to include emoticons. To make this possible I'd add a EntityResolver trait that rustodon can implement for the two cases.

The EntityResolver would have the following methods that all return an Option<String> to confirm that the entity is recognised and valid:

• resolve_emoticon(name: String): resolves to the image URL
• resolve_hashtag(name: String): resolves to the hashtag URL
• resolve_mention(name: String, domain: Option<String>): resolves to the mention URL
• resolve_url(url: String): resolves to the URL given (allows blacklisting of URLs for example)

You'd then just pass in an instance of EntityResolver to the parser and it'd spit out the HTML.

What do you think?

Currently (well, as of 6d5637b in #31) we publish them as AP but Mastodon doesn't see them if you paste the URL into the search bar for some reason. It would be nice to figure out why this is, and make it work with the minimum amount of work possible.

Methods on most of the models are sorely underdocumented atm.

i believe this is a regression?

/cc @y6nH

It's really nasty regex templating atm. We could fix this pretty easily by writing the posticle parser using Nom; i was originally going to and then didn't since it was easier to just port over the twitter-text regexes, following QuietMisdreavus's egg-mode.