Coder Social home page Coder Social logo

feoblog's Introduction

FeoBlog

FeoBlog is a distributed blogging/social networking system designed to protect you as a user. FeoBlog does this based on some core principles:

  1. Your data should not be held hostage by a single service. (ex: Facebook, Twitter).
    If you decide you don't like a service, you should be able to easily copy and reuse your data elsewhere. Likewise, your user ID should be able to migrate with your data so that your followers know you're the same user in both places.

  2. Your data should be resilient to censorship and server outages.

  3. Your data should not be modifiable by third parties.
    People reading your posts should be confident that it has not been altered. e.g.: Servers or other middlemen should not be able to insert ads into your data.

  4. You should be able to create/use clients to view your data as you wish.
    This is unlike platforms like Facebook and Twitter that make it difficult to access your social network's data.

  5. As a server administrator, you should be able to block content as required by law for your jurisdiction.

For more information on how FeoBlog accomplishes this, see: How Does It Work?

Other features

Planned features

See https://github.com/NfNitLoop/feoblog/milestone/1 for a list of features planed for v1.0.

Unplanned features

There are certain features that I do not plan to implement, because I think they are detrimental in social networks.

  • Edits or deletes. Content you post is cryptographically signed and visible forever, unless you revoke your userID. You can reply to your content to make corrections or amendments, however.

The Name

I'm not a great UI designer, so my blog will be a bit feo. Fe2O3 is also the chemical formula for rust, and this implementation is written in Rust. :p

Getting Started

If you don't want to set up your server right away, check out the v0.1 Demo on YouTube!

If you want to build FeoBlog from source, or modify it, see the Development documentation.

Otherwise, you can download a prebuilt release from the GitHub Releases page.

Run the server

Once you've built or downloaded feoblog, you can run it locally by just running:

feoblog serve --open

This will:

  • Start a server on localhost:8080. (You can override w/ the --bind option)
  • Create a database called feoblog.sqlite3 in the current directory.
  • Open a web browser window pointing to your new empty database.

Create a User ID

By default, http://localhost:8080/ will show you the plain HTML version of the site. This is a version of the site that's indexable by search engines, and readable by software and browsers that don't have JavaScript available.

To do more than just read existing content, you'll need to use a client. FeoBlog comes with a built-in client that runs in your browser.

Click the "Client" link to open the in-browser client.

Next, click the "Log in" link.

At the bottom of the page, click the "Create new ID button". This will generate a new user ID for you. It'll look like a random string of characters. For example: A719rvsCkuN2SC5W2vz5hypDE2SpevNTUsEXrVFe9XQ7.

The page will also generate a password for you. It's important to save this key in a secure location like a password manager. You can't change or reset this password. (It's a cryptographic private key that corresponds to your public ID.)

Add Yourself to the Server

Now that you've generated a userID for yourself, you need to tell the server who you are.

A FeoBlog server doesn't contain any passwords, all it knows is a list of user IDs that are allowed to post content to it. Since all content is cryptographically signed by a user, the server can verify that a post came from you without your password.

So, using the userID above, to add myself to the server I'd just run:

feoblog user add A719rvsCkuN2SC5W2vz5hypDE2SpevNTUsEXrVFe9XQ7 --on-homepage --comment "Official FeoBlog Blog"

You can do this by stopping the server with Ctrl-C first, or by running the command in a new window. (But if you stopped the server, make sure to re-start it before the next steps!)

The optional --on-homepage argument says that posts you post to this ID should appear on the Home page of the feoblog, as well as in your individual user page.

And the optional --comment X argument is just a comment to help you, the server admin, keep track of who that ID is. It's only ever shown in the output of feoblog user list.

Log In

Return to the "Log In" page in the browser.

Paste your userID (not password!) into the "Log In As:" field, and click the "Log In" button. You'll get a warning that your profile doesn't exist. (We'll write one next!) Click the "Confirm" button.

Now you're "logged in". You may be surprised that no password was required. "Logging in" to the client just tells it to present data to you as if you are that user. Don't worry, a password will be required to write any data.

The client is built with the idea that you may manage multiple identities. If you generate another ID, you can "log in" as that identity as well, and the client will remember so that you can easily switch between them.

To help distinguish your identities, you can (and should!) give them different names and colors. Just edit the "Name" and "Color" fields as you wish. Changes are saved immediately. Colors should be 3- or 6-digit hexadecimal colors like #03c or #0033cc. Here's a handy color picker for you.

Create Your Profile

User IDs are not a great way to remember people. Thankfully FeoBlog supports user profiles. There, you can set a name for yourself and provide a short description of yourself and/or the purpose of your blog.

Click on the "My Profile" link.

FeoBlog again warns you that it can't find an existing profile for you. If a profile does exist, you have the option to "Sync from another server" so that you can re-use (or modify) the existing one. But since we're creating a new ID, click "Create New Profile".

For now, the important parts to set are:

  • Profile Display Name -- this is a friendly name or nickname to display instead of your long randomly-generated userID. You should set this, but it's not required, if you really prefer being an anonymous number.
  • The "Your profile here..." text box serves as a description for you and/or your blog. Write whatever you want. This box accepts "CommonMark" Markdown formatting.

Once you've got those set, now paste your password into the "Private Key" field, and click "Sign".

This will automatically generate a cryptographic signature for this content. If everything still looks good, click the "Send" button to send this profile to the server.

Write Your First Post

Click on the "New Post" link at the top/left of the page.

This interface is very much like the "My Profile" page. Fill out the title and body of your post, then sign and send the post.

You can view it in "My Feed" and (if you enabled --on-homepage above) on the "Home" feed.

Linking

Since FeoBlog content is distributed, and may be hosted on multiple servers, you should avoid hard-linking to a particular server. If you want to link to a FeoBlog userID or post within your post, use relative links, like this:

Did you see the [FeoBlog] [first post]?

[FeoBlog]: /u/A719rvsCkuN2SC5W2vz5hypDE2SpevNTUsEXrVFe9XQ7/
[first post]: /u/A719rvsCkuN2SC5W2vz5hypDE2SpevNTUsEXrVFe9XQ7/i/2F6NB6PYKDTPGTc9dfaQHpmPzd3LSjVgBuC6qa2hcLUJA74LbZpV8wL5HoXDmvzyfZWaX6sLyg3DoGtqh3t2rJt5/

Of course, if you're linking someone outside of FeoBlog to a particular post, you can link them directly to a page on a particular server like this:

https://blog.nfnitloop.com/u/A719rvsCkuN2SC5W2vz5hypDE2SpevNTUsEXrVFe9XQ7/i/2F6NB6PYKDTPGTc9dfaQHpmPzd3LSjVgBuC6qa2hcLUJA74LbZpV8wL5HoXDmvzyfZWaX6sLyg3DoGtqh3t2rJt5/

The URLs are a bit long, but many services (like Twitter) will shorten them for you anyway. Plus, the URL contains a globally unique ID which can also be used to cryptographically verify the contents of the post. If any one server goes down, the /u/... relative path can be used on any other FeoBlog server that contains a copy of that item.

Advanced Topics

I should probably write more about these things? Tell me if you'd find them useful.

feoblog's People

Contributors

nfnitloop avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar

feoblog's Issues

DAG metadata for censorship detection

FeoBlog "blogs" are organized as an unordered¹ collection of Items so that an individual server may deny storing certain Items. However, this means that, when looking at data stored on a single server, it's not possible to determine whether any of a user's data is missing. To do so, one would have to find a list of Item on some other server and compare it to the one in question.

To enable this type of checking against a single server, we could add optional metadata to the Item type which lists previous Item IDs published by this user ID. Like the rest of the Item, this data would be cryptographically signed by the user's key, so unable to be modified by servers. Clients could walk that DAG and report on any missing items.

IMO, server sync is going to be enough to detect censored Items. During sync, the client compares lists of Item IDs from two servers and copies over missing Items. If a server denies POSTing an item, the client will notify the user, and the user can detect the censorship.


  1. Though posts/Items are commonly ordered by their timestamp, there is nothing in the data structure that enforces that, unlike a DAG.

Better setup.

I really want to use this service, but right now there seems to be only one user and one website, with the UI being not the best. Is there a detailed guide on how to set up your own instance?

"Reply posts"

This is like a comment (#1) , but is a fully-fledged post. It would appear on a feed or the home page like other posts.

However, it also has additional metadata that marks it as a reply to some other Item.

Having that metadata available would allow some nice UI features:

  • Optionally displaying the original post inline
  • The ability to display forward references from an Item to any "Reply posts" that reply to it.

Better server maintenance tools

As a server admin, I should be able to use the CLI to:

  • See how much data users are using.
  • Delete and/or ban particular content/users I find objectionable.
  • Delete data that is no longer used. (ex: users that are no longer followed)
  • Find out why a particular user/Item is on my server. (Who follows this person?)

In the meantime you have to make DB calls yourself.

Add "Share" button(s)

Since there's there are raw (/u/_/i/_/) links and client (/client/#/u/_/...) links, it ends up being easier to share the client link, though the other one would likely result in better SEO and discoverability. Add a share button. It could:

  • Share to Twitter
  • Copy Link
  • ???

Windows builds broken: Rollup creates files with colons in the name

Summary

When Snowpack generates files via snowpack build, it ends up generating files that have colons in the name.

Initially, these seem to work when I'm running the rust server in dev. mode, which passes through file requests to the underlying file system. However, when I attempt to do a release build, which bundles files up into the executable, the required files do not exist.

This also breaks the ability for rollup to do a release build. It itself can't find the files it generated. 😣

Steps to reproduce

Take a look in build/web_modules/common

  • On Linux/MacOS, you'll likely see a file named __node-resolve:empty-1777c4cc.js
  • ⚠️ But on Windows the file will be called __node-resolve. It will be 0 bytes.

This is because file names can't have a colon in them on Windows. However, file paths can have a colon in them, which causes the bit after the colon to be interpreted as a stream when using NTFS file systems. You can see this in this output:

C:\Users\Cody\code\feoblog\web-client\build\web_modules\common>dir /r __node-resolve
 Volume in drive C has no label.
 Volume Serial Number is 3894-D9B7

 Directory of C:\Users\Cody\code\feoblog\web-client\build\web_modules\common

02/20/2021  09:41 PM                 0 __node-resolve
                                   358 __node-resolve:empty-1777c4cc.js:$DATA
               1 File(s)              0 bytes
               0 Dir(s)  357,425,332,224 bytes free

This issue still exists even if I upgrade to Snowpack v3.

I'm not sure if this is a Snowpack bug or a Rollup bug, so I've just reported it here against my own code until I find the culprit. :)

A bit more detail

This seems to work in dev mode because the expected file name is directly requested via the browser. RustEmbed then asks the filesystem for that file path, which also ends up opening the NTFS data stream.

However, bundling the files likely just lists files on disk and tries to include them in the binary. Likewise, copying or zipping the files would probably break this functionality. Right now this is a blocker to having a working feoblog web client on Windows. 😢

See:

Current Status

To do:

  • Work with the Rollup team to merge and release rollup/rollup#3972
  • Ping the Snowpack team to create a release w/ that version.
  • Update Feoblog to use that version of Snowpack
  • Abandon Snowpack, switch to esbuild.
  • Confirm it works on Windows.
  • Enable Windows build automation.
  • Release a Windows build

Implement size quotas

  • Servers should be able to set data quotas for particular users.
  • Servers should be able to set default/maximum data quotas for followed users.
  • Users should be able to set quotas for blogs they follow. (Ex: I want to follow X, but only cache the latest 10MiB on my behalf.)
  • There should be a command to show quota usage.
  • There should be a command to clean up over-quota data. (Right now, we don't preemptively delete it.)

Advanced, possibly future features:

  • Separate quotas for Items and file attachments?

Create a logo and/or icons

Maybe just think about branding in general? In particular "blog" is not quite accurate. And "Feo" was a funny pun for a while but may not really attract new users.

Example names: Disapora, Mastodon, Scuttlebutt. Single word, unique, not necessarily related to what it is.

User-configurable styles/themes

Out of the box, FeoBlog uses its embedded styles.css and client.css files to render the plain HTML view and client view.

Users will probably want a way to provide their own styles for their own sites.

Likes/Reblogging

I wrote in the v0.1.0 README.md:

Reblogging [is an unplanned feature]. I [believe] there should be a higher barrier to sharing others' content. You'll need to comment, post, or "Reply" post to share content to your followers.

But, the more I think about it having a lot of posts like

⬆️ OMG This

is probably even more annoying. If I implement a reblog functionality, I could limit it to the feed, and add an option to not display reblogs for people that don't want to see that.

Support multiple image sizes for an attachment

Related to #20 -- maybe allow attaching multiple versions of an image with different sizes?

Hmm, this might be a bit complicated.

First thought: Add some "metadata" to the Attachment protobuf message that allows alternative sizes.

But ... wouldn't I want all attachments listed in the top-level repeated Attachments.file? Maybe there should be an Attachments.meta? But then clients that naively copy all Attachments may get redundant copies of images? Hmm. I'll need to think about this one a bit more.

Profile Photos

Right now, profiles only contain an identicon based on their public ID.

  • Add the ability to attach a profile photo w/ a profile.
  • Add the ability to attach more than one profile photo.
  • Add the ability to reorder attachments. (The first photo will be the main one.)
  • Maintain previous profile photos (attachments) when editing a profile.
  • Document which photo formats are accepted. (JPG, PNG. GIF?)

My current thinking is that profile photos will just be attachments to the Profile object. Since those are backed by a content-addressable store, editing profiles won't require re-uploading new photos.

The server should expose user feeds as RSS / other feed formats.

Right now the server makes users' posts and feeds available as plain HTML, and as data accessible via the FeoBlog REST API.

However, to allow consuming a FeoBlog blog from third party systems like feed readers, we should also expose the feeds as RSS, and/or Atom, and/or JsonFeed.

  • should link to the plain HTML version of the page. (But see #22)
  • Should probably only serve blogs of "server users", so that folks can't accidentally start following a feed that doesn't actually get regularly updated on this server.
  • Maybe even further limit to only users on the homepage? Or add as a per-user option? Need some consideration here.

Short URLs

Currently, URLs to posts on here are incredibly long, and it would be nice to have "shortcuts" (ex. t.co/XJK98Y)

Redirect JS-enabled browsers to the JS client

The UI of the JS and plain HTML versions of the site has diverged a bit, and TBH the JS version is much nicer. For a better initial experience, redirect browsers that have JavaScript enabled to the corresponding URL in the client.

  • Should include an option to disable the redirect.

Support attachments from iOS (& Android?)

Right now you have to drag/drop attachments into the web UI to add them. This doesn't work on iOS (and probably not Android?)

I suppose I should add some UI element that's more discoverable than drag & drop to enable that.

List of Servers

I should compose a list of servers running FeoBlog, once there are some.

  • What's the server address?
  • Does the server have a specific purpose/community?
  • Is the server accepting new users?
  • If so, how (to whom) does one request access?

Right now, AFAIK, this is just https://blog.nfnitloop.com/. If you're running another server, please do comment and let me know! :)

File Attachments

Users should be able to attach files to a post. This would make sharing images, PDFs, etc. possible.

Rough plans are:

  • Implement a content-addressable store.
  • Re-use whatever hash-algorithm NaCL signatures currently use, since we're already using it.
  • File names, hashes & sizes are stored within the protobuf.
  • Standard URL sub-directory where files live.
  • File uploads to the file names can be performed by anyone.
  • File attachment quotas may disallow attaching large files.

Additional work:

  • Update the client to know how to sync file attachments along with their Items.

Continuous Integration

Need to get some automated builds and releases on this.

  • Automatic builds for develop branch. I don't care about warnings at this stage. OMG Rust has so many warnings.
  • Automatic builds for pull requests.
  • Automatic builds & release for release stage. OK I should probably clean up warnings for that.

Oh, right, also, some tests. 😬

Document issues w/ ActivityPub.

One of the first people I shared FeoBlog with asked "Does it support ActivityPub?" and I had to say no.

I should create a FAQ or somewhere to document these kinds of things, and this question in particular.

The Short Version

Until then, here's why FeoBlog doesn't support ActivityPub:

  1. ActivityPub is federated, not distributed. Your userID is tied to a particular server (DNS hostname). That does not work with the data structures and security measures that FeoBlog was built upon.
  2. The ActivityPub standard doesn't have a way to verify the contents of a posts, so accepting ActivityPub data would mean that FeoBlog clients wouldn't be able to verify all of their data.
  3. ActivityPub relies on the concept of posting messages to users' "inboxes". But in FeoBlog, a user may exist on multiple servers, so there may be no known (and online) "inbox" for ActivityPub to post to.

See https://www.w3.org/TR/activitypub/#security-considerations for some of the unanswered security concerns.

In particular, I don't see there how servers or clients can validate that data they received is actually from the supposedly originating user.

Meanwhile, FeoBlog only accepts signed data. As a result, its data model doesn't need an "inbox". Being passed data for a user operates the same whether it's from that user, or from some other service on their behalf.

Drop dependency on Moment

I added Luxon, and it seems to be a smaller/better library. But because moment is scattered around the code I keep accidentally using more of it. :p

UserID revocation

When a UserID becomes compromised, or a user just wants to delete their account, they should be able to create a revocation Item. Servers should honor this item by:

  • Refusing to accept any new items for that user.
  • Refusing to serve any existing Items for that user (except the revocation Item itself).

The server should also delete the content for that user, but may do so asynchronously. (ex: via a clean command at some later time.) This could allow someone whose key has been compromised a chance to recover their content and publish it under a new key.

  • The /u/:userID/proto3 endpoint should list 1 Item, which is the revocation item, so that other servers that sync from this one will learn of the revocation.

There's a TODO here:
https://github.com/NfNitLoop/feoblog/blob/develop/protobufs/feoblog.proto#L114
... but the more I think about it, the more I think a Revocation should be its own item_type. I don't want the option of specifying a Profile.display_name, about, servers, or follows.

Support (re)compressing image attachments

When you attach a very large image, or paste an image (which seems to always paste as a PNG), the file size can be quite large.

Offer an option to re-encode the image as a smaller jpeg (or webp) image to save space.

Block Users/Items/Attachments

To control spam, objectional content, and abuse, and to comply with legal requirements, server admins should be able to:

  • Block a user ID
  • Block an Item ID
  • Block an attachment (via its content hash)

Blocking one of those should:

  • Prevent it from being served
  • Disallow POSTing it again.
  • Optionally, delete it from the database.

Additionally, we should have commands to find out the reason that blocked content showed up on our instance in the first place:

  • Command to list which users have attached a particular file. (To detect all users responsible for a particular offense.)
  • Command to list users who have followed a particular user ID. (To detect users who use follows to allow abuse.)

Keyboard navigation

Use the keyboard to navigate through items in the client.

ex: j/k for next/previous items.

GDPR issues

See: https://www.reddit.com/r/rust/comments/o80zh4/feoblog_v040_released_today/h3367dw/?utm_source=reddit&utm_medium=web2x&context=3

What are the obligations servers have under GDPR?

My layman's understanding is that under GDPR users must be able to:

  1. Request any data a server has about them.
  2. Be able to request that their data be deleted from a server. (within some timespan?)

The REST API can already list all of a user's Items, so that may take care of point 1.

And eventually I'll implement #5 -- is that enough to handle point 2?

If folks know other GDPR obligations, please leave comments, IANAL.

CLI-based on-demand sync

Currently, servers are pretty simple.

  1. Has a list of users/follows.
  2. May allow POSTs from those users.
  3. Serves that content.

All of the sync logic is written in the client.

It would be nice if I as a user could run a command from the CLI to sync posts. That way I could easily make a copy to bootstrap a new server, or create a backup, or just grab stuff before I go offline for a while.

Add filters when viewing a post's comments.

I recently implemented filtering for the user's feed.

Eventually, when there are many users on a server, a user might want to filter which comments are shown in reply to posts. For example:

  • Include users I follow
  • Include users followed by OP
  • Include all (other) users on the server.

I'm not going to bother with this until I get some more users, though, and this actually becomes an issue.

robots.txt

FeoBlog should include a robots.txt

Immediately after sharing a link to a live server for the first time, it got hit by several bots, and they generally requested a robots.txt.

I should read up on the modern format of robots.txt and include an appropriate one.

Can they do wildcard matching? Do I want to allow/deny specific sections? (Maybe deny /client/*?)

Expose Item validation errors via HTTP 500

I'm writing a new rss->feoblog client for Deno. I was getting a 500 "Server Error" from the server. That's not super helpful. Should expose what failed validation.

I saw this on my actix web console:

[2021-07-04T02:05:33Z ERROR actix_http::response] Internal Server Error: Error { inner: ValidationError { message: "Timestamp is required" } }

Make sure that gets returned via HTTP.

Drafts can cause the wrong timestamp to be used

I just posted minutes ago, but somehow the post is backdated 18 hours. !?!?

I think I figured out what happened. Since the drafts feature was introduced, if there was something in the text field (and there was in this case), we load the text and the timestamp associated w/ that text.

I cleared the text, wrote a new post, and posted it without even looking at the timestamp. So it ended up getting posted w/ an old timestamp. Oops.

I think the common case is going to be posting with the current timestamp, so I should probably make that the default behavior for both new posts and saved drafts.

Maybe I can just allow the timestamp to be blank to mean "now" and leave it blank by default?

Better "Log In" metaphor

Right now the client has you "Log In" as a user. But you don't provide any password to do so. Really you're just configuring the client to act as if you are logged in.

It feels a bit like a kludge. Is there some better language / UI to represent this?

Support for different database backends

Right now, FeoBlog uses an SQLite database. This simplifies maintenance, and should scale enough for individual use, or use among a small group of friends. But SQLite does have limitations with high write loads.

Currently, database operations are all abstracted through the Backend type. It should be easy to add a new implementation, but I'd need to plan for a few things.

  • Do I want to maintain multiple backends?
  • If not, how do I allow backend implementations to be maintained by others without requiring lock-step development?
  • Config file support so database passwords don't need to be specified as command-line arguments. (Which is also good to have in general, I suppose.)

Web-based server admin?

Right now, user administration is performed via the CLI. That's not terrible for a server run by a programmer for a few of his friends. But others might prefer a web-based UI.

How do we do this?

  • Re-use nacl crypto, and create a special "server admin" UID?
  • How do we prevent replay attacks?

Add a "Follow" feature to the UI

Right now, following a user, and knowing whether you already follow a user, is a bit error-prone. You've got to copy/paste the userID into your Edit Profile page.

The UI should:

  • Show you that you're following a user when you view their user profile.
  • Offer a Follow button
  • The Edit Profile page should accept a user ID and prompt the user asking whether they want to add that ID to their list of follows.

Faster Sync

Now that I've got some "blogs" with lots of "posts", the initial sync can be a bit slow.

For example:

image

There's probably room to parallelize the sync more than it is already.

I think I can also walk down the list of items instead of fetching the full list then doing set comparisons. Though I doubt that's the slow part, it's probably just the latency overhead of copying items from and to a server one-by-one.

Better `--open` functionality on Linux

See:

// TODO: This opens up a (AFAICT) blocking CLI browser on Linux. Boo. Don't do that.

Right now I'm just using the webbrowser crate to open a browser, but on Linux that might open a blocking browser, which will block the server from actually starting.

There's an open issue for that here:
amodm/webbrowser-rs#18

--open still might work for a user, depending on what they have set up as their default browser, and which launcher it can find, so it's not necessarily fully broken, but it would be nice if this were consistent with Windows & MacOS behavior.

Better browser caching for static files

I thought I'd need support for this in rust-embed, but as I wrote up pyrossh/rust-embed#140 I realized a workaround would be simple:

Create some wrapper that calculates an ETag (and also Last-Modified date?) on server startup or lazily on the first request. Then serve static files w/ that ETag so browsers will cache them longer.

Tools for migrating to a new ID

If a userID is compromised, or its private key is lost, there should be some tool(s) for migrating content to a new userID (pub/priv key pair).

  • The tool should scan all content for a key, and re-post it under a new userID.

Optional features:

  • Preview items of content before reposting them.
  • Server-side integration to allow doing this for userIDs that have been revoked? #5

Drafts

If I'm writing a post and navigate away from that page then return to it, it should restore my previous post. Losing long posts this way would be pretty annoying.

Browsers try to save form data for you these days, but I think because I'm running a single-page webapp which just removes the element when you navigate away, the browser doesn't know how to save/restore that state. (Plus I think my Svelte code is explicitly starting out with empty state.)

Make the "feed" page the default page in the client

When I visit blog.nfnitloop.com, the thing I usually want to see is the feed of all my follows' (and my) posts. But it currently takes me to the "Home" view by default:

image

This is just because we redirect to the client from /, and I'm trying to mirror the URL structure from the web site in the client. However, I think we can make an exception for the home page, give it an explicit /client/#/home URL, and redirect /client/#/ to the user's feed.

Periodic server-side sync

In addition to #25, it would be nice if the server would periodically sync data for "server users" so that their content would be available without first having to manually sync.

May also want to do this in conjunction with #2 to allow enabling/configuring this option?

Comments

  • Users should be able to comment on any Item (including other comments).

  • Clients should have a way to query for comments in response to an Item.

  • By default, the displayed comments should be limited to:

    • Those followed by the author of the original Item.
    • (optionally) Additionally those followed by the logged-in user.
  • Comments should not be rendered on the main HTML-only home page.

  • Comments may optionally be rendered in clients' feeds (chronologically, detached, but linking to the Item they respond to.)

  • Comments should be rendered when viewing an individual item.

  • Comments are not Posts. In particular, they lack:

    • Titles
    • The ability to attach files (once that's available)
    • The ability to inline images. (TBD)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.