urbit/talk

Urbit notifications and chat module

talk

talk is the frontend for :hall, the urbit messaging and notifications system.

talk is a simple flux app that gets loaded by tree as a module.

Developing

The desk/ folder in this repo mirrors a desk on an urbit planet. Source files live outside of this folder, we compile them in using watchify / sass and then copy the /desk onto the desk we're using for development on a planet.

Our sass depends on bootstrap mixins, so the urbit fork of bootstrap is included as a submodule.

First:

git submodule init
git submodule update --remote

Then:

npm install
npm run watch

Deploy

Simple:

cp -r desk/ [$desk_mountpoint]/

If you have urbit installed in ~/urbit with a planet called sampel-sipnym and have mounted the home desk:

cp -r desk/ ~/urbit/sampel-sipnym/home/

Contributing

If you have a patch you'd like to contribute:

• Test your changes using the above instructions
• Fork this repo
• Send us a pull request

Distribution

Compiled main.js and main.css get periodically shipped to the urbit core. Each time these compiled files are moved to urbit core their commit message should contain the sha-1 of the commit from this repo.

talk's Issues

Webtalk has to be reloaded a few times the first time

Or else it hangs at a blank page. Didn't check the JS console at the time, sorry...

[minor] Page scrolls when someone talks

If you're scrolled up from the bottom at all, the position will still move when someone says something new, making it a pain to read backlog.

(I don't know if this is what was on Anton's older branches - I put those under @galenwp just in case they had something useful, since they didn't look identical to the stuff here)

Long messages get rendered poorly

The message container seems to have a static height. Not ideal, especially now that messages can be any length.

scrollTop isn't set reliably

You may notice this when scrolling up to fetch more messages, the scroll position within the message list will be set a bit higher than where it was before the fetched messages were prepended. I've also noticed something similar when new messages are appended to the bottom.

Hovering messages shows duplicate meta info

Not sure if this is a glitch or a feature but it looks like a glitch to me. Also makes it difficult to copy/past messages.

Joins made by webtalk aren't "safe"

ie they don't follow the best practices for initial joins, like only asking for messages from the last day. Causes urbit/arvo#576.

Unknown speech type: %eval

render an "evaluating..." or sth placeholder while the server is computing a #hoon message result

;who STATION does not work

The syntax checker in talk will not allow me to type anything past ;who.

I understand that this probably means that ;who STATION is not a valid expression.

I will try to venture into :talk and figure this out, but if someone beats me to it please let me know. I don't imagine it's more than a couple of lines.

Strange link rendering in firefox

I saw this in Firefox 50.0.2 on Ubuntu 16.04

Not sure what other info would be useful. Happy to answer other questions if necessary.

Station membership is broken

Clicking a station doesn't reveal a membership list. Not sure what's going on here.

Messages bleed into each other on narrower windows

This is due to the .gram elements having a set height, which I know is required for the react-infinite plugin. Not sure what the best way to handle this is, maybe somehow retrieve their natural height before passing in to Infinite? But then how do you deal with window resizing, check and rerender on resize event?

List of lines attachments are displayed without hovering

Should just display on-hover like is the case for list of tanks etc.

Code execution causes React Infinite to get confused

Because we don't do the weird hacky thing of measuring message height off screen code execution can mangle the calculation of the height of the message container.

Code output will now show on hover.

No messages when filtering to a station that has a timestamp

I have stations added with timestamps, e.g. ~samzod/urbit-meta/~2018.2.26..04.05.58..7dbf

If I filter to these in the web UI, I get no messages. It looks like the filtering should be ignoring this timestamp:

Menu size bug on mobile

Since we change from position: fixed to position: absolute when scrolling on mobile we have width issues.

Error: [%ap-abut-bad-bone %talk 256]

Been getting this for about a week -- pops up iteratively in the middle of my Talk feed:

[%ap-abut-bad-bone %talk 256] 

But it seems like everything still works fine. I can see and send messages from both the CLI and the browser UI.

What's up?

No distinction between normal messages and hoon eval

This is exacerbated by the static heights completely hiding the eval results, which do have code-block styling.

No 'offline' indication

The interface gives no indication when it's been disconnected, the 'offline' class never gets added to the body.

(div {}, [child1, child2]) used instead of (div {}, child1, child2)

Resulting in each child must have a "key" prop warnings, as react can't tell that the list of children being passed through is static.

@ speech should be italic

Class is on the container, but css isn't up to date.

Split talk messages are shown backwards in stream

Reversing the talk stream also reverses any auto-split messages in that stream, "long talk message" becoming

message
talk
long

Fixing this would probably require backend support for threading/grouping of split messages.

Menu box extends into talk message area

Code execution needs a higher z-index

Or something. The neighboring text appears above the output.

Timestamp overlapping in skinny Chrome

Running Google Chrome 54.0.2840.98, with a browser width of 960 pixels, I see the following when hovering over a message:

Not a huge deal, but it can be hard to read the timestamps. Just figured I should report it.

Webtalk prints moon names like comets

While on the console, moons are printed as their parent planets with a "^" (i.e. all moons of ~ropdun-sormyr get printed as ~ropdun^sormyr).

While on webtalk, moons are abbreviated as comets (i.e. ~lagdep-nomren-ropdun-sormyr gets printed as ~lagdep_sormyr). It should instead be printed as the console version does it.

"say" message class should be computed per speech component

The fat and mor speech types contain multiple elements. If you @emote with an attachment, the attachment shouldn't be styled as say; similarly, a say line inside of a mor list shouldn't color the whole list.

~ship-name doesn't get autofilled to ~ship-name/inbox

May or may not be the issue behind #37. Also see urbit/arvo#438

Unbind from redundant subscriptions

Should probably call window.urb.drop when a subscription returns here.

input line descends at exactly 10 characters

Safari 9.1.1, OS X 10.11.5

Leading spaces bug

Action:

Result:

Not compatible with Safari

Unclear what the issue is — but grams don't seem to load.

Backlog fetching screws up scroll offset

I think I introduced this when trying to fix the jitter caused by new messages incoming.

"A component is `contentEditable` and contains `children` managed by React."

Adapt urbit/archaeology-factor@437e416 for the writing component, to reduce the flood of warnings.

Webtalk on moons

When loading webtalk off a moon, it tries to load from the moon's Hall. Since moons use their planet's Hall, there's nothing there, so no messages ever load. It should be sending subscriptions to the planet instead.

boquet should be rendered as an array of strings

Which matches the (set path) it is in hoon better than the current array of arrays of strings; and is easier to manipulate on the client.

Note: this issue mainly concerns urbit/arvo:mar/talk/report.hoon

Can't DM comets

Apparently comet name parsing in the audience field is borked.

Show in-flight messages as greyed out, hide metadata

In flight messages should show as received when we get them back from the server. That's a css issue — but there's something in the JS that isn't properly marking the message as '.same'.

Options offset padding is incorrect

https://www.dropbox.com/s/y64mti15ru9weea/Screenshot%202016-02-25%2017.26.42.png?dl=0

Probably maladjusted based on #head being the wrong size before.