Neb Reference App (Possible) Features List

This is a list of things to consider for the app.

Tech Notes To Address

This is a quick dumping ground for tech things to address. They're more implementation details for the app than they are part of the vision. I don't have anything else set up to collect them at the moment. So, I'm putting everything here for now. (Of course, these are requirements. Different apps can make different decisions on anything that's not explicitly specified)

TKTKTK

Brain Dump

This isn't sorted and there's probably duplication and contradictions. That's fine, the purpose of this section is to collect as many thoughts as possible.

Plan out moderation controls in the app: Filtering, Mutings, Blocking, Not showing preview images. (There's not really a way to prevent following based on the fundamentals of the web without introducting authentication and authorization. That will be done at a later stage)
Look at DOMPurify for HTML sanitization: https://github.com/cure53/DOMPurify
Accessibility. Make sure the app works in a way that supports accessibility best practices.
Maybe don't have different types of feeds in the table of contents. That way folks don't have to categories. Folks can set up their own differnt types of feeds without having to make any specific distinction and other folks can just grab what they want regardless if the type.
Handle pagination so the entire history of a feed can be pulled. (Parsing could check to see what the latest post it knows about it is and then keep going through the feeds until it finds it in the indexes)
Consider splitting posts into their own files
Consider having the main feed file for any given feed list all the posts that are part of it along with addresses for the individual files. That way sites can confirm that they've got access to everything for a timeline
Think more about redistribution. That is, when one site reposts something from another site the reposter should host a copy of the content. This is so big sites can repost without sending an overwhelming amount of traffic to smaller sites. The content would be signed with the original site's key so everyone would have to ping that to get it for verification. So, not a big difference when it comes to text only, but when images are videos are involved it would help sites not get knocked over by "the hug of death"
Apps should periodically ping the table of contents to see if new feeds were added
Thinking about the public/private key pair. There should only be one per site, but it's possible to use the same one for multiple sites. (Really, there's no way to stop that so it needs to be accounted for)

TBD on how to display things in the UI if multiple sites of the same key. Not a big deal for listing the individual feeds since those would be associated with a specific site, but for the metadata about the site you'd need to make sure that e.g. both avatars showed up.
For v1, standardize on RSS or Atom, but don't use both. The reason is that there will need to be extensions and having to spec for two different feeds types adds overhead for no real benefit I can see.

The plan right now is to standardize on RSS. Both formats would work, but RSS is the term main term that's used for feeds. (And yeah, I'm making this decision based on the language that's used. If there ends up being a technical reason to switch, that's fine, but I don't like saying "grab the RSS feed, which is actually an Atom feed.")
For CSS styling, thinking about a three step process: Initial App Styles, Post Styles, App Override Styles. The App should always be in control at the highest level, but the goal is to provide the ability for post authors the ability to style their content.

No matter what approach there will be times when thing go sideways. The goal is to minimise it (and also have a quick way to disable post based styles if necessary)
There should be a disable CSS/Styles button for every post to turn them off if things go to weird.
The initial version of the app will only have one view of feeds. Future versions will have multiple views that allow for things like different collections or filter or whatever.
Mute word lists are a must.
Figure out how to hide stuff that's already been seen as an option. Or maybe a link to "jump to next unread" or something like that so everything stays visible but you don't have to scroll past everything if you reload the app and start at the top.
Add views where you can see just the feed sets from individual sites (e.g. if the have multiple)
Should posts be marked as read in all views whenever they are seen in one? Need to prototype to see how that feels.
Focus on ease of deployment
Integrate with git from the start. Just version everything on main every time a file is updated. Then, have a on-click "publish" button that pushes the repo up.
The publish button should only show if there's an upstream repo.
Other forms of publishing can be added in later iterations. (straight SCP, SFTP, or FTPS, I can never remember which is which)
Include "reduced motion" style controls (e.g. provide config to prevent GIFs/etc... from animating unless clicked or all together.)
Figure out how to handle podcasts.
App should have feature that prompts for alt text for images. Like, when you put in an image a dialog shows a preview and an empty box for typing
Figure out how to handle alt text embedded in metadata. Instinct is to show it to users on image upload to let them choose to use it or not or to overwrite it. Need more import on the implications of the different approaches.
In the CSS, have the demos show how to do dark mode vs light mode
Set up the app so that it can toggle between light and dark mode for previews.
Allow site specific CSS overrides. Maybe if you do that you don't need to add the second pass of CSS? but probably you'll still want that as the final override
Provide templates for new posts and shorts.
Store content in play-text files using markdown as the default processor.
Only require file names for images regardless of where they are stored.
Treat the app as a holistic site builder. (e.g. don't worry about what other things might do outside of it. If something else messes with a file and breaks it it's not worth trying to hunt the external stuff down.
Provide a search for images.
Provide a way to do bookmarks.
Maybe ways to categories/tag bookmarks (not required when you first make them, but somewhere in the interface)
Make a feed of posts that you reply too so folks can follow replies? Might be an interesting way to filter them, but maybe too much overhead.
Content Warnings as part of the feeds
Multiple Built In CSS themes
Ability to customize CSS themes
Ability to apply custom stylesheet to all feeds.
Ability to apply custom stylesheets to individual fees.
Provide a way to browse tags for second order (and maybe third order?) feeds as a way to aid discovery.
Make sure to work with RSS that doesn't have any of the Neb extensions.
What about only delivering the markdown? Let the processing happen in the app. idea being to reduce the side of the feeds. would need to have a flag that identified that the post was markdown. the flag could also be set to html, but if it wasn't there the assumption would be the post is html.
Provide for draft posts that don't go into the feed. (Unless, of course, you make a drafts feed)
Start everything with a single feed then add the ability to add different ones going forward.
If someone follows lots of folks it'll take a while to pull each batch of updates. Some consideration needs to be given to the number of connections and bandwidth.
Proxy servers can help a lot with the connections and bandwidth by doing aggregations and potentially dynamic responses. But, they are not (and should not be) required. While this means some folks may have sub-optimal experiences there isn't a requirement to gatekeep everyone.
Have the ability to identify proxy servers/services.
Have the ability to publish to to one place but have links point to a CDN (I think this happens naturally since the publication location isn't explicitly aware of the web locations, but need to keep this in the back of the mind in case something related comes up)
Look at all the things possible on other social networks to pick from: follows, favorites, boosts, reposts, quote posts, bookmarks, replies. Is there more?

Think pinboard style interface too for tagging and taking notes on bookmarks

Read later in addition to bookmarks? Probably makes sense.
When you follow a feed, present two buttons. One for public, one for private. (that is, don't make a default choice, make it an explicit one that the person makes)
Ingest OPML to populate feed lists.
Make all the default CSS examples have both light and dark mode.
Make the default CSS payload for posts show up just once in the RSS feed, but have a place to add more for each post individually.
Spec out a standard set of variables that are suggested for using in the CSS with the goal of making it easier for folks to override them in the App if they have different accessabilty needs.
Figure out what the best approach is with the default CSS to make things like enlarging fonts easier.
Figure out best set of standard things to put in the reference app for CSS to make things as accessible as possible.
Create a CSS scrubbing spec. That is, a clear list with a subset of CSS that should be allowed to pass. It's up to apps to make their own decisions, but this would act as the reference for apps to be confirming to the spec for the network.
Ability to prevent GIFs (or anything animated) from playing by default.
Ability to set GIFs (or other animated stuff) so they only loop a few times then stop, but you can click/tap to start them again.
Make sure emojis work in titles
Was thinking about specing for things like :blobfoxheadphones: strings that get replace, but like, the HTML is right there, you can just insert the image. Maybe there's standardized class you can add that sets the height to the line height of the text that folks could use as an option.
handle markdown
plugins?
Folks who follow hundreds or thousands of other folks are gonna be interesting. They'll be pretty constantly pinging. Not sure what the experience will be because you won't know something isn't there until it shows up. Thinking that timestamps will generally be ignored from the feeds in terms of sorting. They'll just show up in the order they were received. (it'll still show the relative time though). This will also help prevent issues with feeds with incorrect timestamps that are either in the future or way back in the past. (and for posts where the timestamp can't be parsed)
Show table of contents for posts that have h1s, h2s, etc.
Keep track of the posts that have been viewed and collapse them somehow so you can skip to stuff you haven't seen.
Provide search inside your feeds.
Ability to create filtered views of feeds in the app based of filters, account groups, etc.
Public and private block lists.
Ability to hide images by default.
Ability to prevent animation until you click on something
Ability to hide avatars all the time or just when browsing the feeds of folks you follow during discovery.
Some amount of verification will be possible via the public/private keys. TBD on a system to add external verification. The feels like something that would be an extension at least if not something left to an external entity entirely. (i.e. the verification could come from an external source and then an additional cert could be added to the /.well-know/neb/ directory, but the app itself wouldn't be responsible for creation of those certs. Just validating them if they exist.
Ability to expand threads directly instead of having them link off (or having to open new tabs like I end up doing most of the time)
Have the ability to expand a the feed a post is from directly inline (thinking here about things like photo feeds where it would be cool to open it up and see the other photos a person took without having to jump to their profile)
Look into hosting with: https://coolify.io/pricing/
No followers at first. maybe never. maybe the only ping is if you write something on your site and do a webmetion style thing (but with a bunch of processing power required to generate the signature from the post to try to cut down on spam.

TBD on favorites. that probably makes sense. A way to ping an acknowledgement that you're into something without having to write something about it.
Scaling to huge numbers is gonna be a tricky thing, probably. I expect some number of servers will fall over. This is where some of the shared caching/serving comes into play. But like, for someone who has 100K people following them, they'll need a beefy setup. This is one thing that gets addressed by centralized services that is way harder (or at least more expensive) to deal with on individual sites. I'm not sure what to expect, but I'm pretty certain there will be things to overcome.
Gotta examine how to deal with things like sending giant files to DDoS someone. This will largely be deal with at the hosting level, but I want to have some info about it in general.
Alt text text boxes are directly visible instead of having to click on the alt text button to open them
Figure out how to handle updated posts. Could be that you track the URLs along with the global IDs? Or look for an updated timestamp for the global id? (that seems to make sense, but needs some more thought and examination)
How about a way to "star" certain feeds so that you always see them up top in chronological order and then you see the rest of the un-starred stuff below that? Idea being to let you make sure to keep up with the folks you're most interested in on the main timeline

-- end of line --