profile: redesign

[matildepark]

• [x] Back-end work for contact simplification

Simplify contact-store to store a map of ship to contact instead of storing a map of group to map of ship of contact.

• [ ] Front-end simplification to reflect this change as per design handoff

Includes statuses for profile cards (#56)

[matildepark]

Design work is in progress (as of yesterday).

[matildepark]

urbit/urbit#4264

[matildepark]

Possibly can include #56? Depends on networking logic, point to point subscriptions would make it work fine; recurring fetch would make it out of date frequently.

[urcades]

Brief overview on the major touch points for the new profile work: Part One

Imagining we've just opened up our personal urbit, the first major change of note is the way we render the profile in the top bar.

Top Bar

Note: We've removed the display of the patP in favor of only displaying the sigil, which should reflect changes made to it, via the profile, accordingly. Given there is now a single editing surface for a single profile-representation used throughout Landscape (until we build a more robust and still-simple multi-avatar system), it only makes sense that we reflect color changes, and the decision to use an avatar in the top bar:

Clicking the ship representation in the top bar will bring you to your profile immediately. We are no longer bundling ship settings and identity within a single interface. It should be obvious, but ship settings are now accessed via the gear that now resides next to the "urbit representation".

Moving on!

Profile Page

After clicking the ship representation in the top bar, an urbit pilot lands within their profile. It's hyper minimal for now:

The pilot-editable elements include:

1. a 600x300 header image
2. the sigil presentation (can support color changes, or be 'covered' with an avatar)
3. a pilot-set name (replaces their patP where applicable)
4. an arbitrarily-long markdown-supporting 'description' textarea
5. a toggle for setting the profile to public or private

and last but not least, in a move to begin supporting a notion of discoverability in urbit:

6. a list of public groups an urbit owner can choose to surface on their profile

These fields are also forever and always OPT-IN — you do NOT -NEED- to fill them all out. None of them rely on one another — this is by design, and should ideally remain so.

The fields are presented as a whole, and cannot be selectively 'turned on' or 'turned off' — if your profile is PUBLIC, than all information a pilot edits will be visible to the world. If the profile is PRIVATE, than any edited information is only visible by ships who 1) have been directly DMed and had the profile shared with them and 2) members of a group in which a pilot has made their profile visible/public.

Anyone viewing a private profile only sees a monochromatic sigil, and the pilot's @p

The profile, as one might imagine, can become arbitrarily rich, and someday support a lot more functionality, but we're purposefully keeping the scope of editable/displayable elements low, in order to see how they fare on the network.

Unedited or "Default" profiles, or profiles of unbooted ships, will look incredibly bare for the time being:

This isn't ideal, and perhaps we can report back on their azimuth info, to populate profiles with interesting info, but we'll see how Ethereum holds up, and whether we mitigate Azimuth via another system.

Editing a Profile

If an urbit pilot is looking at their own profile, they see the option to EDIT it.

If a pilot is looking at another person's profile, they can MESSAGE the user. Other options, such as PAY or REPORT/CENSURE/BLOCK, will find their way into the profile display when they are built.

The editing interface looks very similar to the profile interface itself:

Each of the fields are displayed in a non-fancy manner. The most complex field is the "Add a Group" field, which allows a pilot to filter through a list of public groups they are a member of and list them as affiliations on their profile.

Summary

So, this is an overview of everything profile viewing/editing is concerned.

There are no longer "Group Profiles" in their current form, or the ability to edit a profile in the context of a group. If you view a list of group members, you'll be given the option to visit another person's profile, which occupies the entire view/screen, as shown above.

Here's how you'd share your profile with a group:

If you don't share your profile with a group, you'll simply appear as a basic urbit ship/sigil/@p

[urcades]

Brief overview on the major touch points for the new profile work: Part Two

Now that we've covered the primary profile display, and its editing methods, we now divulge secondary and tertiary interfaces that can be found throughout landscape.

Mini Profiles

Anywhere you can find a ship representation in Landscape, we should couple them with onClick micro profiles, which display a small selection of information mirrored from one's primary profile:

An example of a card that represents "my identity":

An example of a card that represents "someone else's identity":

There are small point of distinction between both cards, such as being able to message "someone else", and being able to set a text-status on my own mini profile (if/when we ever develop this). Actions made available on the Mini Profile should mirror the actions one can take on a ship via its profile.

Mention-completion

This profile mirror is simple:

When I begin to type a sig ~ to start writing a ship's name, we should bring back the autocomplete box, which should mirror a minimal amount of profile information, such as a ship's pilot-set name, their ship color, and their avatar if set.

Leap

Last but not least, Leap should begin to render out snippets of a pilot's identity information if any of it has been set:

In this example, programmatic status, sigil color, and a small pilot-set status message is included in Leap's completion set.

[urcades]

As I was writing out some of the secondary/tertiary interfaces, I was reminded that these may be quite limited depending on how we treat the privacy model of profiles — for example:

If I search "~ravmel-ropdyl" in leap, and I am a brand-new, completely fresh urbit, I'd expect this to effectively function as a |hi sent to him. Despite never being in a group with one another, and him sharing his profile to me, should I be privy to any of his profile information?

I think this sort of begs the question: Should an additional field be added to profiles to make them universally public (and thus able to display information via a ship search in Leap) or private? I can imagine a private profile would operate such that I perform edits on it, and selectively share with groups, and any members of said group are granted view access to my profile info, including via Leap.

I imagine if we offer this capability, it'd look like this:

And thusly remove or disable the ability to 'not share' your profile with a group.

Would appreciate any thoughts here!

[urcades]

cc @tacryt-socryp re: everything above — tear it up, we can chat about how this is currently stated and how it should evolve

[urcades]

cc @tacryt-socryp

Adding some additional designs promised during our chat/review. All of the above thoughts are contingent on a toggle in one's profile editing experience that allows them to set the profile to public or private:

Onward —

DM "Share Profile" banner

While talking to someone for the first time after identities are released, you will see a banner in the DM:

If your profile is Private, you'll be given a chance to share out your profile in a banner pinned to the top of your chat. If dismissed, your profile edits can be shared with the recipient in the chat's settings. Note the details like your sigil in the text input still retaining a "default" black and white appearance.

If your profile is set to "Public", the DM banner will appear, but note that your profile information has been shared with the recipient:

Any edits made to your profile, including your name and avatar/sigil edits will be mirrored into the chat automatically.

Joining a Group

Private and Public profile settings also affect one's experience joining a group:

If your profile is set to private, you'll be asked explicitly while joining a channel if you'd like to share your private profile to the group, making it visible to the group members:

A preview of your profile is listed under the checkbox, to ensure you're aware of what you'll be sharing.

If your profile is set to public, the same modal will grey out the already-toggled setting:

[urcades]

A small note ( again, cc @tacryt-socryp ) about MiniProfiles:

In line with our general approach to heavily simplify our first take on urbit identities, we're removing a lot of extra options from the interfaces:

Instead of a dedicated icon-button, clicking the ship's sigil/avatar now takes you to their profile. While viewing other people's profiles, you are only (for now) given the option to DM them.

As we expand the possibility of profiles/identities, we'll be sure to make these minimal interfaces more useful.

[matildepark]

• @tacryt-socryp talked to @belisarius222 about contacts networking model
  • Should be fine to get ahead on naive approach on having ships connect directly; only blocking change is on Ames API to send a single message to a set of ducts, compared to an individual message at a time
  • Ship to ship connections should be made more feasible from a networking perspective
  • Urbit should support ship to ship connections not through group owners performantly, we shouldn't be forced to design around flow Ames experience with point to point networking

Front-end work starting now.

[matildepark]

Relevant issue: https://github.com/urbit/urbit/pull/4264

[matildepark]

@urcades to extend this issue with status-inclusive mocks after https://github.com/urbit/landscape/issues/120#issuecomment-763212383.

[urcades]

Updates for @tacryt-socryp

MiniProfile Cards, with Statuses:

Apart from the change to their interfaces, these cards are also larger than previously presented, 250px square, for increased ability to set a meaningful status. Clicking the profile image takes you to the card owner's profile.

It's worth noting that in -all- cases a pilot's identity is surfaced in Landscape (in chat, in posts, in notebooks, in collections), they should be able to be clicked, and a MiniProfile should be able to be presented.

Status in Profile Pages

Here are two states of "Someone Else's Profile":

On the left, this pilot has not set a status, so no space is occupied on their profile to display one.

On the right, another pilot's status will appear as a full-width banner stacked on top of their header. Think of it as a banner you wave — a statement to immediately set the present context.

In each of these cases, this is how your profile will appear from other people's perspective.

On the other hand, if you are looking at your own profile, you'll see the following:

Note that this field is editable even though you have not entered "Editing Mode" for you profile!

This is a deliberate choice, to reduce the amount of friction in setting a status, which should be more accessible than not.

If you enter "Profile Edit Mode", this status interface will not change state — it's effectively always able to be edited.

[tacryt-socryp]

@urcades Thoughts on making the sigil in the top-right corner a drop-down that has a "set status" button and a "view profile" button?

[urcades]

That's a rad idea, I'll sketch up something quick to get a sense of how this could work — a dumb version and a slightly more nifty version.

[urcades]

Okay, further updates @tacryt-socryp :

Note: This simplifies our existing 1.6 specification for our top bar — now we can simplify it even more, using the sigil as the container for navigating to System Preferences (you can always leap to it too):

Using new indigo dropdown and Alert components, we should be able to use the sigil to enter a dropdown which allows us to set the status from any Landscape context:

This additional interface now makes for three distinct interfaces you can set your status from:

1. Your Profile itself
2. The "top-bar sigil" menu item, "Set Status"
3. Wherever you can invoke your own MiniProfile

[urcades]

The "Nifty Idea" I mentioned before would be to leverage Leap and create a new command called "Status..." or "Set Status..." which could be typed and autocompleted within Leap.

This would likely be a 1.7 update, given the updated Leap interfaces are roughly scheduled to be implemented at that time.

[tacryt-socryp]

I've written the "profile view" and created the "edit state", but have yet to write the contents of the edit state yet. Attached is my current progress, showing an entirely empty profile.

[urcades]

It's lookin' good — very excited this is coming together

[matildepark]

~2021.1.25 — networking infrastructure conversation with @tacryt-socryp, @philipcmonk, @belisarius222, @joemfb

- PM: Concerned about everyone getting information from everyone else. - LA: There’s an additional case where you can fetch profiles from Leap and subscribe to it (unless you have no information) - 1. You join the group (we can be fuzzy about how leniently we fetch things — we have no requirement, it could be last 100 with msgs, no need to get everything at once) - 2. When you initiate a DM, we want to. - 3. When we fetch someone directly, we want to. - LA: This is because we want to share a status, a single string, that we get updates to, not fetch. The other main thing to note here is that the permission model is not directly dependent upon groups — you could have permission to access contact bc you’re in group or bc you’re 1:1 or it’s public. The networking demand is extremely dissimilar to graph or metadata — which uses groups - PM: To be clear, you can say “I want to show only some or none of my profile information to this group” and when someone subscribes, you check and see “do I know them”. - The only concerning part is the way joining a group would make you subscribed to everyone else in the group, because the other stuff is sufficiently manual. - LA: We talked about heuristics to avoid making 2000 subscriptions upon joining a group, so we could find something to sufficiently alleviate that. My idea is, when you first join a group, you initiate zero subscriptions and would only initiate contact subscriptions upon joining a graph in that group. The initial request would parse the last n messages (100?) of that graph and fetch contact information for those people - PM: I suspect you can probably get that working where it’s the only last 100, then it’s anyone who posts, you get info about them. Your groups might take some time to warm up at first, but it’s not that bad. I think that’s more complicated than basically relying on our existing communication hierarchy. For someone in a group, you just subscribe to the group and the owner sends that information. - LA: One of my primary motivations for doing this differently than that topology (while it would work) is to do the initial Posts module on a per ship basis. This is about what’s coming down the pipeline in 1-2 months. - PM: Useful to know. I think the way that Ames works now, doing this for Contacts would be 99% as expensive as doing this for Posts, because the expense is in the retries, not the data. Related to that, we need some kind of remote scry before the non-groups version of Posts is really feasible. - TB: As in favour of remote scries as I am, I’m not sure that’s true. I was thinking about — it’s n squared, but in what — n packets per backoff interval. What is n and what’s the times involved? I think we should assume a few thousand — n is 10,000 people, 10,000 subscribers per publisher. A decent average, maybe conservative. If you have 10,000 * 10,000, you have 100 million. 100m packets per some interval. For an offline ship, how often should we ping them? Every 10 mins? If every 10 mins, how many packets per second is that? I’m not convinced the packets the publisher has to push out induces a terrible burden on the network in total. - PM: The difference between 2 minutes and an hour is a 30x difference, but the difference between 10M and 300M, square root of that, is 20,000 * 20,000 - TB: It grows linearly, not quadratically. - JB: Even if it’s just the 10,000, it’s that 100,000 packets every 6 seconds? - PM: The 10,000 number, it may be reasonable to assume not every user will be connected to more than 10,000 people, but the infrastructure ships will need to handle more than that, since there will be many different groups. - LA: It’s true, but only in a packet forwarding capacity. They wouldn’t need to actually have any of these contacts subscriptions. We could also introduce pruning logic at the individual ship level to attach a timestamp to when the subscription was made to a variety of ships we’re subscribed to in the contact hook. We could hard cap the subscription count before we’re comfortable with the networking characteristics. I’m not pushing for some absolute “perfectly meets the product demand” with the contact stuff so much as I’m interested in us starting to do experimentation with how we could do this point to point level networking without federation, even if we have to make tradeoffs to see what parts of the network get pushed on pretty hard and also trying to do the least intense version of this to start with. Even if that’s limiting the number of connections the hooks are willing to deal with. - PM: There are no takebacks, though — if you talk to someone and they’re not responding, you can’t just undo it. I’m fairly convinced that the answer to doing this right is remote scry, because #1: you can take back by stop trying to call them, and #2, you can push the cache to the edge, turning n squared to an n problem. With that in place, this is doable. Without those, we’ll get into a situation not as bad as Links (since everything is faster now) but the ratio of data to metadata packets will plummet. I expect we’ll be unable to handle a 10x of users. Right now, we probably could. - TB: Basically right, but I have another thought about what we can do to decrease the rate of spurious packets sent around: if we switch to a different idea of forwarding, where right now, if I haven’t heard from you, I send stuff through your star on an interval until you show up, right? That’s not the only way to do that. PM suggested a year ago that the right way to handle peer discovery, or reconnections for peer discovery, is, if I’m trying to push a status update to a planet who doesn’t respond in 2 minutes, I request the star to ping me when he’s next online. Next time the star hears from him, they tell everyone who’s asked. There’s a one-time, so offline ships aren’t having packets sent to them, avoiding n squared packets. - LA: That sounds amazing. I really like that. Another related thing to the remote scry and Ames is, I think the remote scry doesn’t obviate the need for Ames in any degree because long-running subscriptions are very important in a remote scry world. If we get retry dynamics right so they aren’t a big beast (as we should), subscriptions will still be important in a remote scry world, because you’ll subscribe to the hash of the data. You’ll want to be able to push a lot of data to everyone. You shouldn’t say “we’ll never be in a situation where your ship pushes data to 50,000 people” — I think many people will be in that world. - JB: What that helps with primarily is the no takebacks problem. If what you can’t take back is a large piece of data, that’s a concrete space leak. That’s a real concern we can’t resolve without large networking semantics. I think there’s two problems — - TB: That’s O(1) though, you can deduplicate, it’s the same piece of data. It’s not that bad of a problem. - PM: Depends how big n is. If the ship count is large, it’s still a large piece of data. - TB: There is the metadata Ames stores, I guess. I feel like that stuff grows pretty slowly. - JB: There’s also the question of whether it’s a reference to persistent data. I wanted to make a more general point. I think there are two concerns to this type of typology. One is, the sheer rate of data flow, whether data itself or metadata maintaining the flows and reconnection logic. I think we could cope with that volume of data with this network size just because the network is faster. Even if everything is through the galaxy, we could do 100,000 packets every 6 seconds. The thing I’m more concerned about is the proliferation of subscriptions. I think the lifecycle is not handled well in userspace, I think it’s the biggest problem we have, and we’re pouring gas on it by doing this. Even local subscriptions aren’t handled well. - TB: What’s the problem — space leak, resubscribe logic? - JB: The proper lifecycle of a subscription is not something that is known or broadly established, at least that I have a lot of confidence in. Adding a ton more subscriptions is something I’m quite worried about. - PM: At a high level, I can’t think of a single other project that does this kind of point to point many to many subscriptions that Links did, and that we’re proposing here. Everyone else federates them in some way. I don’t think it’s just a lack of will. - TB: Example? - PM: Email. Mastodon. All those old PBFT, Tendermint, they have a limit of validators in the 100, 200 range because of, “everyone has to communicate with everyone else”. Systems like Hotstuff, they make it so everyone doesn’t have to talk to each other. - LA: We do have the stars, just like Ted said, which allow us to do a variety of networking wins on the metadata being sent. If we’re worried about the metadata being sent, we can put resources toward that, and Ted has given us a proposal, and that would vastly eliminate data sent to offline ships. - TB: Not trivial to implement. - LA: On the other, there’s the amount of data being sent, in the case of Contacts, it’s not that much data: not the size itself nor number of updates. I’m worried about the metadata in this case, I’m not worried about the data itself. As PM said, Contacts is 99% of the load of the Posts case. Joe’s concern is, I’m sure valid, it may be worth going and looking at that stuff. From the Gall level, with the push-hook architecture, we’re doing everything we can to optimise this. We have a single resource identifier. If Links is K*n squared, we’re n squared. We have a stable wire and a single resource. So if the problem is Ames metadata, isn’t it pertinent to get ahead of that? - PM: Yes, but we have to actually get ahead of it. There are solutions to this general problem. BitTorrent is a solution to this general problem. Distributed hash tables are a solution to this problem. Remote scry would be that. If that’s the long-term answer, then I don’t think pushing on this aspect of the system is actually going to make that much clearer. I don’t usually say that. - TB: I guess, in my mind, long-term it’s basically inevitable that there are going to be these pieces of data, one ship wants to publish to n ships, and there will be many ships publishing to n ships, some piece of data. We can’t shoehorn everything into a group paradigm necessarily. I think there’s a problem where you have n squared, logical subscriptions and you also have an irreducible n squared long-term, for the data flow, publishers to subscribers. You have n publishers, each of them have subscribers, whatever. From an infrastructure perspective we can say “don’t do it,” but that’s not an answer, because people will just do it. JB hit it on the head because metadata packets are swamping the data packets. If the actual data load is too high, that rests with the application developer or the users who can’t handle it. But the actual data pushed around that way, even if n squared, won’t be enough to swamp the network. Metadata packets will if we’re not careful. What we can do to limit the metadata, to reduce the packets sent per unit of time, is to do some kind of delegation, some efficient spanning tree. That and you reduce polling. Now we have n squared polling. That’s a non-starter, long-term. The thing that’s appealing about remote scry is that you get a more efficient spanning tree because the intermediate nodes can cache, and I can publish to just a few stars primarily and those stars each handle some amount of that load, and the replication factor at each piece of that is relatively low. I publish to 10 stars, and the stars publish to 20 users each. This is a way of federating it; another way of federating is with groups. The group hosts publish to everyone else, making fewer total connections, and fewer logical subscriptions that span the larger number of subscriptions. I think some of this is irreducible, but the actual data flow from that isn’t too terrible onerous if we have a reasonable efficient way to broadcast it across the network. Remote scry allows hierarchy based, relaying based federation. Groups help because they allow group-based federation. And the other dimension is, can we reduce polling. Those are the levers we have. - PM: We can transmute the polling from a networking cost to a storage cost, and the storage cost is generally cheaper. - JB: The word van Jacobsen uses in this context a lot is “dissemination networks” and that’s the right framing for these kinds of use cases. Something else I don’t know how practical it is, but it’s occurring, is that these topologies in a human sense creates a power law for content people are interested in. One way to look at the content-centric networking approach is that it’s a lazy federation where you’re discovering what actually needs to be federated at the last minute based on the actual interest expressed in the network. I do think that the general framing that’s been offered here to solve the problem is right, I think LA’s point is right that subscriptions will always be around, peers expressing durable interest in some category of information in some resource will always be around, and we will have to solve the metadata problem. I agree with PM that we want to solve that consciously, deliberately, so I don’t think it will help to turn up all the dials first and try to make it work later. - **PM: My recommendation would be to send this profile information via groups for now. That shouldn’t affect the product experience. That should avoid a scaling bomb.** - LA: **That won’t affect the product experience, as you said, though I am interested in knowing to some degree — are we thinking or planning on putting resources toward this, since it’s a burgeoning problem?** - PM: Yeah, we almost — this quarter we almost put resources into remote scry and also subscription reform that could be relevant. They seem connected — remote scries might be too narrow of a framing and it’s just the query side of Ames, basically, in particular you might be able to do a push-oriented remote scry where it’s more like subscriptions, but without it being the way that Ames works. Subscriptions with a DHT. Unfortunately, both remote scry and subscription reform got deprioritised for this quarter. Hopefully next quarter. - TB: Next quarter — if we actually make some improvements to Ames scaling in 6-9 months, we’ll probably be okay. If we do get better asymptotics on ships publishing information to offline ships, we’ll see an across-the-board performance increase. - LA: I’m not as interested in the remote scry implementation or the large variety of big brain ideas we have for improving Ames performance, but specifically to Ted’s proposal to the polling reform, because that solves the majority of the metadata issues we’re discussing. - TB: We might want to do that as part of stars actually doing forwarding (urbit/urbit#2041), since that gets us a whole other layer of scaling. - PM: I’m not sure there are more stars than galaxies online right now? - LA: There definitely are. 68 stars to 23 galaxies, stably a 3:1 ratio since July. - PM: The work cutting off polling is orthogonal to the routing problem, I think. - TB: I think it’s not orthogonal because, if we can make it that you subscribe to a sponsor when someone goes offline, we’ll have to mess with the routing logic anyway and redesign routing and peer discovery. It’ll be a more explicitly stateful system. Once we have that, we might as well get it to work in a federated way. - PM: My only evidence for it being harder is that we tried to do it federated, fairly seriously, and we failed. I think it’s possible but it’s not simply a matter of “We’re in there mucking around, we can just fix this.” - TB: Do you remember what problems we had? I think we had packet forwarding loops. Was it all loops? - PM: It’s the balance between loops and more than once messaging and less than once messaging. Anything to cut off loops made them not live; anything to make them live made loops. - TB: One thing I was inspired by van Jacobsen is that loops are fine, you discard the duplicate packets. - PM: It makes sense for a read, but it doesn’t make sense for a forward flow. - JB: I think that’s true of almost all content-centric networking stuff. - TB: They don’t have stateful agents trying to get some other stateful agent to do something. Our pokes are all unique, every single packet is unique. - PM: No, because we have to be able to repeat these. We have to be able to say, “I didn’t get an acknowledgement, so I’m going to send another message.” Are you saying we should put a counter in there? That would be a solution, to say when we retry we increment a counter. - TB: The way NDN solves this is that it matches each packet with the request. So if I send a poke through a star, and that star has heard the ack — is that right? - PM: How does it route the request? - JB: It does ad hoc, prefix routing on the pass. - TB: You configure it somehow, that’s the NDN somehow. - PM: If they don’t answer, can you make the same request again, or will it be dropped? - TB: I am not entirely sure how to handle retry. How NDN handles retry is something I don’t get. - JB: At a packet level I’m not sure they’re supposed to be discriminable. - TB: In Ames, they’re not either. - PM: They’re not supposed to be. If they aren’t, how do you know it’s another person asking for the same thing and not forward it, vs. this is a loop — how do you discriminate? - MP: So is the short-term goal just the groups thing? - PM: I think so. LA? - LA: Only if the polling reform is happening simultaneously. - PM: I don’t know what we can push. We can’t push PKI, we can’t push log rollover. - JB: We’re stuck with the machine that we have. - LA: Are we confident in the increase we have as is, given the low number of ships on network, that this will be a problem in the short term? - PM: It will become a problem at 10x our size. It’s hard to say where in the middle that issue is. I’m wary of introducing — - LA: Where we can’t scale to meet the load. I think my takeaway is to find ways to push the polling reform. If we move to a star-based routing system and a star-based polling system that would be likely a more immediate gain for our actual userspace development flows. It would be more reactive, but more of an immediate performance gain to increase our capabilities at a userspace level, than jumping immediately on remote scries when it becomes pertinent. Polling is a more actionable proposal in our networking framework.

[matildepark]

Current status: networking model work needs to be rewritten for group-federated pattern, UI needs detail attention — @matildepark to handle that as per meeting tomorrow.

[tacryt-socryp]

@urcades how do we save / submit the form state? https://github.com/urbit/landscape/issues/120#issuecomment-760010913

[urcades]

Yo @tacryt-socryp , great question, will try to illustrate clearly here:

The shortest possible answer: While in "edit" mode, we should provide a very obvious bar-based interface that allows pilots to either implicitly discard their changes (using "Cancel") or save their profile edits (using "Update Profile").

This bar's z-index should effectively "float" over the content underneath, in case it is not clear – this keeps the ability to save or cancel/go back never hidden out-of-sight of the viewport.

[matildepark]

• Networking implementation still in progress; involves changing push/pull-hooks to use a set instead of a unit of resources, defaulting to current functionality, adding the functionality to send a card to all resources in the set.

Front-end still in progress.

[matildepark]

• Networking mostly implemented
• Some lingering questions around public profiles without a group
• Pinned group submission / display still an open question
• Most other FE stubbed